Two Exceptions to Rule Them All

There’s no better way to start a new year than a hearty, poignant rant. To set the bar up high right off the bat, I’m not gonna be picking on some usual, easy target like JavaScript or PHP. To the contrary, I will lash out on everyone-and-their-mother’s favorite language; the one sitting comfortably in the middle between established, mature, boring technologies of the enterprise; and the cutting edge, misbegotten phantasms of the GitHub generation.

That’s, of course, Python. A language so great that nearly all its flaws people talk about are shared evenly by others of its kin: the highly dynamic, interpreted languages. One would be hard-pressed to find anything that’s not simply a rehashed argument about maintainability, runtime safety or efficiency – concerns that apply equally well to Ruby, Perl and the like. What about anything specifically “pythonic”?…

Well, let’s talk about Python’s exceptions, shall we?

Inheritance as an API

Saying “API” nowadays is thought first and foremost to refer to a collection of HTTP request handlers that expose data from some Web service in a machine-readable format (usually JSON). This is not the meaning of API I have in mind right here, though. The classic one talks about any conglomerate of programming language constructs – functions, classes, packages – that are available for us to use.

You can interact with an API in numerous different ways, but one of them is somewhat less common. Occasionally, besides having functions to call and objects to create, you are also presented with base classes to inherit. This is symptomatic to more complex libraries, written mostly in statically typed languages. Among them, the one that takes the most advantage of this technique is probably Java.

Note that what I’m talking about here is substantially different from implementing an interface. That is a relatively common occurrence, required when working with listeners and callbacks:

as well as in many other situations and patterns. There is nothing terribly special about it, given that even non-object oriented languages have equivalent mechanisms of accomplishing the same objective: separating the “how” from “what” in code, possibly to exchange or expand the latter.

Inheriting from a base class is something else entirely. The often criticized, ideologically skewed interpretation of OOP would claim that inheritance is meant to introduce more specialized kinds of existing types of objects. In practice, that’s almost completely missing the real point.

What’s important in creating a derived class is that:

• like with interface, it needs to override certain methods and fill them with code
• but also, it may do so using a unique, additional API

Combined, these two qualities allow to introduce much more sophisticated ways of communication between the API and its client code. It’s a powerful tool and should be used sparingly, but certain types of libraries and (especially) frameworks can benefit greatly from it.

As an example, look at the Guice framework for dependency injection. If you use it in your project, you need to configure it by specifying bindings: mapping between the interfaces used by your code and their implementations. This is necessary for the framework can wire them together, possibly in more then one way (different in production code and in test code, for example).
Bindings are quite sophisticated constructs. For non-trivial applications – and these are the ones you generally want to apply dependency injection to – they cannot really be pinned down to a single function call. Other, similar frameworks would therefore use completely external configuration files (usually in XML), which has a lot of downsides.

Guice, however, has a sufficiently smart API that allows to realize all configuration in actual, compilable code. To achieve this, it uses inheritance, exactly as described above. Here’s a short sample:

Overridden methods in the above class (well, one method) serve as “sections” in the “configuration file”. Inherited methods, on the other hand, provide an internal, limited namespace that can be used to compose configuration “entries”. Since everything is real code, we can have the compiler check everything for some basic sanity as well.

HTML nr 5 – książka

Właśnie skończyłem lekturę książki Wprowadzenie do HTML5 autorstwa Bruce’a Lawsona i Remy’ego Sharpa, wydanej w wersji polskiej przez Helion. Zakupiłem ją z nadzieją, że wprowadzi nieco porządku w cały ten buzz odnośnie HTML5, którego trudno nie zauważyć, jeśli tylko robi się cokolwiek chociaż pośrednio związanego z tą tematyką. I od razu mogę stwierdzić, że pod tym względem moje oczekiwania zostały rzeczywiście spełnione.

W książce można bowiem znaleźć przegląd kilku elementów składających się na standard HTML5 oraz paru technologii pobocznych, które formalnie do standardu nie należą, ale często są uwzględniane pod parasolem szerszej definicji całego zjawiska/technologii/ruchu/trendu/czegokolwiek-czym-to-jest. Wśród nich mamy takie podstawy jak nowe elementy strukturalne, nowe i przedefiniowane znaczniki opisu tekstu, poszerzone możliwości formularzy i różne drobne usprawnienia składniowo-semantyczne. Nie są one może tak ekscytujące jak “gwiazdy” technologii HTML5, ale fakt ich porządnego uwzględnienia jest według mnie tym bardziej godny uwagi.
Oczywiście nie zabrakło też wielu “nowych wspaniałych API”, dzięki którym możemy chociażby tworzyć SQL-owe bazy danych po stronie klienta i wykonywać szereg innych niezbędnych a właściwych dla stron WWW czynności ;D I tak możemy na przykład dowiedzieć się, co to właściwie jest ten Canvas, w jaki sposób zapewnić wsparcie dla techniki drag & drop i do czego w zasadzie mogą przydać się te całe webowe gniazdka (czyli Web Sockets). Ponieważ wszystko pokazane jest na prostych przykładach, opanowanie podstaw każdego z tych rozwiązań dla ogarniętego programisty nie stanowi żadnego problemu.

Kluczowym słówkiem są tu jednak owe ‘podstawy’. Chociaż różne tematy są tu opisane z różnym poziomem szczegółowości – czasem nawet zbyt dużym, jak choćby w przypadku <audio>/<video> – to jednak w żaden nie jest opisany wyczerpująco. Nie wskazuję tego jako wady, bo przecież mówimy o książce z wyraźnym napisem “wprowadzenie” na okładce. Poza tym w prawie każdym miejscu, gdzie autorzy świadomie coś pomijają, podawane są inne (zwykle internetowe) źródła, z których można czerpać bardziej szczegółowe informacje. Trzeba też powiedzieć szczerze, że właściwie żaden z opisywanych tematów (może poza Canvasem) osobno nie prezentuje się jako specjalnie skomplikowany bądź obszerny. Skondensowane wprowadzenie może więc równie dobrze być całkowicie wystarczające.

Podsumowując więc: lektura okazała się jak najbardziej pożyteczna. Książkę czyta się szybko i bez wielkiego wysiłku, a jednocześnie można się z niej dowiedzieć wielu interesujących rzeczy. Jeśli nawet nie zamierzamy – za przeproszeniem – programować w HTML5, to przeczytanie tej książki da nam ciekawy wgląd w technologie będące podobno przyszłością Internetu czy nawet aplikacji jako takich.

Szanuj programistę swego…

…możesz nie mieć wnet żadnego.

Natrafiłem wczoraj na artykuł opisujący prawdopodobne przyczyny porażki systemu operacyjnego Symbian. Dla niezorientowanych – których, jak przewiduję, może być całkiem sporo – wyjaśniam, że chodzi tutaj o system działający na bardziej zaawansowanych telefonach komórkowych, popularny jeszcze kilka lat temu. Wydaje się, że miał on przed sobą całkiem obiecującą przyszłość, biorąc pod uwagę to, że popularne obecnie usługi typu współdzielenie lokacji czy rzeczywistość rozszerzona (augmented reality) najwyraźniej działały na nim całe lata przed powstaniem chociażby iPhone’a. Coś więc musiało pójść bardzo nie tak, skoro obecnie rynek smartphone‘ów jest zdominowany przez wspomnianego iPhone’a oraz system Android. I stąd właśnie wynika ciekawa nauczka życiowa dla twórców tego rodzaju platform – i nie tylko.

W skrócie brzmi ona: “Dbaj o programistów, który mają tworzyć aplikacje oparte o twoje rozwiązanie”. Realizacja polega na dostarczeniu sensownego, kompletnego i dobrze udokumentowanego API oraz utrzymywania dobrego kontaktu ze społecznością twórców kodu. Symbian nie miał najwyraźniej żadnej z tych rzeczy, a brak pierwszej z nich mogę zresztą potwierdzić osobiście :) Generalnie wrogie (!) nastawienie decydentów do samego pomysłu tworzenia niezależnych aplikacji na tę platformę na pewno nie przysłużyło się w jej dłuższym okresie, co można właśnie teraz obserwować.

Wynika z tego interesujący wniosek: sukces rynkowy rozwiązania takiego jak system operacyjny czy inna platforma programowo-sprzętowa jest ściśle związany z łatwością tworzenia rozwiązań pochodnych (takich jak np. aplikacje), które z nim współpracują. Nie wydaje się to wcale oczywiste, bo przecież z biznesowego punktu widzenia aplikacje można tworzyć na każdej platformie – to głównie kwestia kosztów zatrudnienia odpowiednio wykwalifikowanych programistów, które mogą być przeważone przez późniejsze korzyści. Najwyraźniej jednak nie jest to takie proste, bo istnieje tutaj jakaś nietrywialna zależność… Ciekawe, jaka? :)

W każdym razie można z tego wysnuć optymistyczny wniosek, iż tworzenie bibliotek, platform i API strawnych dla programisty leży w żywotnym finansowym interesie ich twórców. A w związku z tym możemy mieć nadzieję, że liczba tych pierwszych będzie się z czasem sukcesywnie zwiększać.