Archive for Applications

Self-Replacing Script Blocks for Dynamic Lists

2012-01-17 8:52

On contemporary websites and web applications, it is extremely common task to display a list of items on page. In any reasonable framework and/or templating engine, this can be accomplished rather trivially. Here’s how it could look like in Jinja or Django templates:

  1. <ul>
  2. {% for item in items %}
  3.     <li>{{ item }}</li>
  4. {% endfor %}
  5. </ul>

But it’s usually not too long before our list grows big and it becomes unfeasible to render it all on the server. Or maybe, albeit less likely, we want it to be updated in real-time, without having to reload the whole page. Either case requires to incorporate some JavaScript code, talking to the server and obtaining next portion of data whenever it’s needed.

Obviously, that data has to be rendered as well, and there is one option of doing it on the server side, serving actual HTML directly to JS. An arguably better solution is to respond with JSON or similar representation of our items. This is conceptually simpler, feels less messy and is potentially reusable as a part of website’s external API. There is just one drawback: it forces rendering to be done also in JavaScript.

Tags: , , , , , , ,
Author: Xion, posted under Applications, Internet » 1 comment

Proste formaty tekstowe

2011-09-02 23:02

Wprawdzie dobry kod znaczy więcej niż tysiąc słów, ale czasami kawałek dokumentacji jest po prostu nieodzowny. Osobiście uważam, że w tym względzie liczy się prostota i zaprzęganie do pracy takich formatów jak .doc czy nawet .pdf jest niemal zawsze grubą przesadą. Jest o wiele łatwiej, jeśli dokument daje się edytować zwyczajnym edytorem tekstowym.

Ale nawet wśród czysto tekstowych formatów występuje całkiem spora różnorodność. Mamy chociażby kilka opartych na XML-u – takich jak DocBook – że nie wspominając o nieśmiertelnym \tau\epsilon\chi-u. Te i im podobne są językami znacznikowymi (markup languages) i poza sporymi możliwościami mają jedną wadę: są rozwlekłe. Stosunek “sygnału do szumu” nie jest w nich specjalnie wysoki, przez co w swojej surowej formie są one trudniejsze w czytaniu – a więc i w edycji.

Tej w wady są w dużym stopniu pozbawione formaty w stylu wiki, przypominające trochę różne spontaniczne pomysły na formatowanie czystego tekstu spacjami, myślnikami i gwiazdkami. Czasami nie mają one często zaawansowanych możliwości pozwalających na przykład na wstawianie tabel, ale w zakresie oferowanej funkcjonalności są zaskakująco często wystarczające. Z pewnością wystarczają chociażby do postów na forach czy ticketów w systemach do śledzenia błędów.

Jest tylko pewien szkopuł: jest ich mnóstwo. Poza kilkoma wariantami składni wiki, mamy też takie wynalazki jak Markdown albo reStructuredText. W sumie jednak stanowią one tylko część tych co bardziej znanych. Sytuacja przypomina tu trochę pewien szczególny komiks z xkcd. Skutkiem tego jest często konieczność sprawdzania, jakiej to składni używa akurat ta konkretna strona, na której piszemy post lub komentarz, jeśli tylko nie robimy tego regularnie.

Na szczęście przyswojenie sobie nowej składni tego rodzaju nie jest przeraźliwie wyczerpującym wysiłkiem umysłowym ;-) Niekiedy sprawę upraszcza też fakt wspierania przez dany serwis więcej niż jednego standardu – tak robi na przykład GitHub. I dlatego nawet istnienie kilkunastu podobnych formatów nie wydaje się być jakimś szczególnie wielkim problemem.
Porównajmy to chociażby z hipotetyczną sytuacją, gdy w użyciu jest kilka formatów podobnie rozbudowanych i skomplikowanych co XML… Brr :)

Tags: , ,
Author: Xion, posted under Applications, Programming » Comments Off on Proste formaty tekstowe

Automatyzacja językami programowania

2011-07-28 21:11

Zwykłego użytkownika od power usera dobrze odróżnia sposób radzenia sobie z powtarzalnymi zadaniami. Perspektywa zmiany nazwy N plików, skonwertowania N obrazków czy skatalogowania N utworów muzycznych jest odstręczająca już dla niewielkich wartości N, jeśli mielibyśmy wykonywać te czynności ręcznie. Zaawansowany użytkownik w tym celu zakasze jednak rękawy i wysmaży odpowiedni skrypt, który może nie będzie działał od razu, ale za to w końcu poradzi sobie z zadaniem całkowicie automatycznie. Niekoniecznie musi to w sumie zająć mniej czasu niż procedura ręczna, ale na pewno będzie mniej męczące :)

Dlatego też niemal zawsze staram się wybierać programową automatyzację. Wiąże się z tym jednak pewien problem. Otóż języki powłok systemowych (shelli) to nie jest coś, z czym koder ma intensywny kontakt na co dzień. Należą one raczej do obszaru zainteresowań administratorów. W związku z tym wyprodukowanie jakiegoś działającego kawałka skryptu jest często poprzedzone co najmniej krótkim przypominaniem sobie składni i semantyki danego języka. Zasadniczo jest to strata czasu lub – wyrażając się nieco inaczej – czynnik zwiększający minimalną wartość N, od której automatyzacja ma sens.

Ale jeśli nie języki shellowe, to co? Ano to, czego używamy na co dzień, czyli zwykłe języki programowania. Tu niestety nie ma sprawiedliwości: niektóre z nich nadają się do zadania nieporównywalnie lepiej niż inne. Część tych drugich ma swoje interpretowane, skryptowe wersje; przykładem jest choćby javowy BeanShell. Ich odpowiedniość do wersji pełnych nie jest jednak wcale zapewniona. Inne języki zwyczajnie nie mają podobnych narzędzi i zostawiają nas z koniecznością wyprodukowania kompletnego programu.
Tutaj ujawnia się przewaga Perla, Pythona, Ruby’ego i podobnych im języków interpretowanych, które nie wymagają do uruchomienia niczego poza plikiem z “czystym” kodem. Jest to dokładnie taka sama sytuacja, jak w przypadku basha czy innych języków powłoki. Korzyść jest jednak oczywista, jeśli tylko któryś z tych języków jest nam znany: nie ma tu bariery składniowej.

Nie znaczy to oczywiście, że jeśli ktoś potrafi jednym zaklęciem złożonym z ls, xargs i grepa przetworzyć tysiąc plików tekstowych, to powinien porzucić tę sztukę i zwrócić się ku Prawdziwemu Programowaniu™. Zapewne też dobry programista będzie potrafił w końcu wyprodukować ową magiczną formułę, pod warunkiem spędzenia odpowiednio długiego czasu nad stronami mana. Jeśli jednak alternatywą jest napisanie kilkunastu linijek w znanym sobie języku, które zrobią to samo, będą miały spore szanse działać za pierwszym razem i zajmą w sumie co najwyżej kilka minut… to czemu nie? Warto korzystać ze swoich umiejętności nie tylko w ich ściśle ograniczonym obszarze zastosowań.

A jeśli przypadkiem ktoś właśnie zechciał akurat nauczyć się któregoś z wymienionych ze mnie języków, to… tak, polecam Pythona :)

Terminologia rozproszonych systemów kontroli wersji

2011-06-06 19:31

W ostatnich latach rozproszone systemy kontroli wersji (w skrócie DVCS) stały się popularne, zwłaszcza w środowiskach związanych z open source. Warto je jednak znać nie tylko wtedy, gdy pracujemy nad projektami z otwartym źródłem. Jak bowiem pisałem wcześniej, mogą być one przydatne chociażby do małych jednoosobowych projektów. Ponadto bywają nierzadko używane w większych oraz mniejszych firmach. Ogólnie mamy więc duże szanse, aby prędzej lub później zetknąć się z takimi systemami.
Ten post jest adresowany przede wszystkim do osób, które nie miały wcześniej dłuższej styczności rozproszonymi systemami kontroli wersji. Ma on na celu wyjaśnienie wielu spośród tych tajemniczo brzmiących słówek, na jakie nieustannie można się natknąć, gdy pracujemy z DVCS-ami. Istnieje oczywiście szansa, że bardziej zaawansowani użytkownicy również wyciągną nowe wiadomości z lektury (albo chociaż przejrzenia) niniejszej notki. A jeśli nawet nie, to powtórzenie znanej sobie wiedzy na pewno im nie zaszkodzi ;)

Tags: , ,
Author: Xion, posted under Applications, Programming » 3 comments

Proste gesty dotykowe

2011-04-20 19:38

Urządzenia, w których jedyną lub główną metodą interakcji jest ekran dotykowy prezentują interesują wyzwanie w zakresie sterowania i interfejsu użytkownika. Naiwne w rozwiązania zwykle sprawdzają się słabo, czego przykładem może być wydzielenie części ekranu na przyciski kontrolne. Brak skoku oraz fizycznych krawędzi klawiszy sprawia, że stosunkowo łatwo tutaj o pomyłkę i niezamierzone wciśnięcie błędnego klawisza.
Dlatego też ta forma komunikacji użytkownika z urządzeniem wymaga nieco innego podejścia, które wykorzystuje jego mocne punkty i pozwala jakoś żyć z jego słabymi stronami. Można na przykład zauważyć, że palec użytkownika jeżdżący po ekranie (pozwolę sobie pominąć tutaj multitouch :)) przypomina pod wieloma względami kursor myszki i często można z powodzeniem traktować go jako taki. Podstawową różnicą jest brak wykrywalnego ruchu między miejscami interesującymi użytkownika, a co za tym idzie brak również zdarzeń typu hover (mouseover), służących często do wyświetlania podpowiedzi.


Jak się tapuje :) (Źródło)

Jest więc podobnie, ale inaczej :) Ponieważ nie mażemy palcem po ekranie przez cały czas, interakcja użytkownika z urządzeniem przebiega wyłącznie za pośrednictwem zamierzonych gestów. Częściowo przypominają one kliknięcia lub przeciąganie wykonywane jednoprzyciskową myszą, ale ich wachlarz jest nieco szerszy. Wśród nich mamy bowiem takie gesty jak:

  • Tap, czyli po polsku ‘tapnięcie’ ;-) Jest to krótkie naciśnięcie (albo wręcz puknięcie) ekranu. To najkrótszy i prawdopodobnie najprostszy gest (chociaż słyszałem też opinie wprost przeciwne), który służy standardowo do wyboru wskazanego elementu. W ten sposób uruchamia się aplikacje lub przechodzi do stron wskazywanych przez linki. Gest ten jest więc funkcjonalnym odpowiednikiem pojedynczego lub podwójnego kliknięcia w przypadku zwykłej myszki.
  • Long press, czyli dłuższe wciśnięcie. Polega ono na naciśnięciu ekranu i przytrzymaniu palca w jednym miejscu, zwykle około sekundę. Taki gest często daje dostęp do drugorzędnej akcji związanej z wciskanym elementem, a czasami po prostu otwiera menu zawierające większą liczbę opcji. Przybliżonym odpowiednikiem long pressa w przypadku myszki jest więc kliknięcie prawym przyciskiem.
  • Double tap, czyli podwójne tapnięcie. Oznacza to wykonanie dwóch tapów w krótkim odstępie czasu i przestrzeni (na ekranie). Chociaż wydaje się to podobne do dwukrotnego kliknięcia, analogia jest raczej błędna. Podwójny tap wykorzystywany więc bowiem stosunkowo rzadko i raczej tylko w dość specjalnych przypadkach. Jednym z powodów jest fakt, że obsługa tego gestu opóźniałaby każdy zwykły (pojedynczy) tap, gdyż użytkownik potrzebowałby okienka czasowego na “zdecydowanie się” na ewentualne drugie tapnięcie.
    Dlatego też często stosowaną strategią jest obsługa double tapu tylko w obrębie przestrzeni między interaktywnymi elementami. Wtedy gest ten służy do przełączania między widokiem zwykłym a przybliżonym/powiększonym – czyli po prostu do zoomowania.
  • Swipe lub fling, czyli przeciąganie. Podobnie jak w long pressie tu też wciskamy ekran na dłużej, ale tym razem przeciągamy palec w inne miejsce bez jego odrywania. Ten gest w rzeczywistości tysiąc razy prostszy niż nawet ten jednozdaniowy opis i niezwykle intuicyjny, więc używa się go w bardzo wielu miejscach. Obejmuje to: przechodzenie do następnego/poprzedniego elementu, przewijanie długich list, przeciąganie elementów w stylu drag & drop i pewnie jeszcze sporo innych zastosowań. Łatwo więc zauważyć, że odpowiednikiem dla zwykłej myszki może tu być zarówno standardowe przeciąganie z wciśniętym przyciskiem, jak i kręcenie rolką.

Jak widać, istnieją pewnie nieformalne standardy obsługi poszczególnych gestów w taki sposób, aby interfejs użytkownika był w miarę spójny. Zdaje mi się jednak, że ekrany dotykowe – mimo postulowanej intuicyjności – wciąż mogą niedoświadczonym użytkownikom wydawać się nieco zagadkowe w obsłudze. Spójna obsługa powyższych gestów w aplikacjach pomogłaby oczywiście w eliminacji tego problemu.

Tags: , ,
Author: Xion, posted under Applications, Programming » 2 comments

Przenośne aplikacje mobilne

2011-04-05 21:07

Odkryłem niedawno bardzo ciekawy projekt o nazwie jQuery Mobile. Jego założeniem jest uproszczenie procesu tworzenia aplikacji na różne platformy mobilne poprzez dostarczenie odpowiednio przenośnego frameworka webowego. Powstałe przy jego pomocy “aplikacje” (a tak naprawdę odpowiednio spreparowane strony) mają wyglądać i działać tak samo na większości przenośnych urządzeń takich jak smartphone‘y i tablety.

Całkiem interesujące, prawda? Jeszcze ciekawsze jest to, że mimo bycia wciąż w stadium alpha (wersję alpha 4 wydano parę dni temu) całość działa już bardzo dobrze i rzeczywiście spełnia większość swoich obietnic. Oczywiście nie każdemu może uśmiechać się “programowanie w HTML” (;D), ale tutaj jest ono dość ładnie zorganizowane w warstwę interfejsu (odpowiednio spreparowane tagi HTML) i logiki (kod JavaScript wykorzystujący jQuery). Ta pierwsza pozwala między innymi na umieszczanie kilku stron w jednym pliku i efektowne przełączanie miedzy nimi:

  1. <div data-role="page" id="menu">
  2.     <div data-role="content">
  3.         <ul data-role="listview">
  4.             <li><a href="#one">One</a></li>
  5.             <li><a href="#two">Two</a></li>
  6.         </ul>
  7.     </div>
  8. </div>
  9. <div data-role="page" id="one">
  10. ...
  11. </div>
  12. <div data-role="page" id="two">
  13. ...
  14. </div>

Przejścia pomiędzy stronami nieźle imitują natywny UI platform mobilnych, gdyż są zrealizowane przy pomocy javascriptowych animacji zaimplementowanych w jQuery. Co więcej, jak widać powyżej odnośniki mogą być zwykłymi linkami (<a>). Czego zaś nie widać to to, że przy okazji przechodzenia między stronami historia przeglądarki – a więc chociażby przyciski Wstecz i Dalej – działa zgodnie z przewidywaniami i “nie psuje” zachowania aplikacji.
Naturalnie samo przełączanie stron to nie wszystko, bo wypadałoby przecież coś na nich pokazać :) Tutaj jQuery Mobile też prezentuje się dobrze, bo niejako automagicznie dba o odpowiedni wygląd elementów aplikacji poprzez stosowanie wbudowanego zestawu “mobilnych” stylów CSS. Zmieniają one wygląd tekstu, linków oraz pól formularzy na taki, który dobrze udaje kontrolki natywnego interfejsu. No, a przynajmniej może uchodzić za takowy w przypadku urządzeń pracujących pod kontrolą iOS-a, bo właśnie do interfejsu tego systemu aplikacje jQuery Mobile są najbardziej podobne.

Niemniej także na innych platformach (chociażby Androidzie) rezultat zastosowania tego frameworka jest więcej niż zadowalający. Wydaje mi się aczkolwiek, że podobne rozwiązania chwilowo wyprzedzają jeszcze trochę swój czas. Ich podstawowym mankamentem jest brak sensownych dojść z przeglądarki internetowej do większości ciekawych podsystemów urządzeń mobilnych, takich chociażby jak kamera; póki co dostępne są chyba tylko usługi lokalizacyjne. Nie da się więc w ten sposób tworzyć skomplikowanych aplikacji, korzystających ze sprzętu czy bardziej zaawansowanych funkcjonalności systemu.
Jeśli jednak chodzi o proste rozwiązania oparte na tekście, obrazkach i formularzach – a więc jako szeroko pojęte front-endy do zdalnych repozytoriów z danymi – to jQuery Mobile może być dobrą alternatywą dla mozolnego portowania aplikacji między różnymi platformami. Podobnie zresztą rzecz ma się z mobilnymi wersjami zwykłych stron internetowych.

Tags: , , ,
Author: Xion, posted under Applications, Internet, Programming » 8 comments

Bo konsola to też okno

2011-01-26 9:48

Systemy uniksowe dość długo wyróżniały się znacznie lepszym wsparciem dla trybu wiersza poleceń niż Windows. To się w pewnym sensie zmieniło po powstaniu PowerShella, będącego co najmniej równie dobrą powłoką tekstową co bash czy zsh. Jednak przynajmniej w jednym aspekcie Linuksy wciąż mają tutaj wyraźną przewagę. Chodzi o graficzną otoczkę tekstowej konsoli.
W Windows programy konsole uruchamiane są wciąż w starym, w gruncie rzeczy obleśnym i w dodatku bardzo słabo i trudno konfigurowalnym oknie. Nie da się płynnie zmienić jego rozmiaru, zmaksymalizować, nie wspominając już nawet o otwieraniu kilku konsol w zakładkach tego samego okna. Możliwość modyfikacji czcionki czy też kolorów tekstu i tła też jest ograniczona i niewygodna. Dla porównania, okienka konsoli w systemach linuksowych są pod tym względem o wiele elastyczniejsze, zapewniając wszystkie te feature‘y i jeszcze sporo innych. W rezultacie interfejs tekstowy jest tam przyjemniejszy w obsłudze, nawet jeśli obiektywnie ustępuje możliwościami temu windowsowemu.

Czy da się coś na to poradzić, czyniąc windowsowe okienko konsoli bardziej znośnym?… Otóż można w pewnym – może nawet zadowalającym – stopniu to uczynić, lecz w tym celu trzeba się posłużyć zewnętrzną aplikacją. Chodzi mianowicie o open-source‘owy projekt Console2, będący okienkowym środowiskiem uruchamiania programów konsolowych. Technicznie działa on zapewne w podobny sposób, jak mój eksperyment sprzed prawie trzech lat, z tym że oczywiście robi to znacznie lepiej :) W międzyczasie zapewnia też sporą część funkcjonalności okienek terminala pracujących w X-Window, a mianowicie:

  • obsługę kilku zakładek z przełączaniem się między nimi za pomocą konfigurowalnych skrótów klawiszowych
  • wybór domyślnego shella (np. cmd, cygwin albo powershell), a także możliwość skonfigurowania kilku powłok uruchamianych automatycznie w osobnych zakładkach
  • zaawansowaną konfigurację wyglądu, aż do kształtu kursora włącznie
  • obsługę przezroczystości całego okna
  • zmianę jego rozmiaru poprzez przeciąganie za krawędź

i jeszcze kilka innych, w gruncie rzeczy naturalnych funkcji, których w tajemniczy sposób zabrakło w standardowym oknie konsoli w Windows. Jeżeli chodzi o stabilność i szybkość działania, to również prezentuje się nie najgorzej, chociaż zdarzają się problemy, np. z przesłaniem sygnału Ctrl+C w celu przerwania spamującego polecenia w rodzaju ls -r /. Małą wadą jest też konfiguracja, która może zająć trochę czasu i kłopotów, jeśli umieścimy program w standardowy folderze Program Files (wskazówka: należy wtedy poinstruować go, by zapisywał ustawienia w katalogu użytkownika).
Ogólnie jednak moje wrażenia co do tej aplikacji są w miarę pozytywne, lecz pamiętajmy, że rywal jest godny pożałowania ;) Tym niemniej polecam zapoznanie się z tym programem, jeśli dużo pracujemy z tekstowym shellem pod Windows.

Tags: , ,
Author: Xion, posted under Applications » 7 comments
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.