I T.A.K.E. Unconference took place in Bucharest in 29-30th of May. The conference was organized by Mozaic Works. I T.A.K.E. Unconference wanted, and successfully managed, to break the classical conference pattern. Besides the classical presentations and keynotes, it contained workshops, coding katas, coding contests and the interesting concept of “open space”, where participants could gather spontaneously and approach various discussion topics. It was an event for geeks, the proposed themes being True Software Stories, Architecture and Design Practices, Beautiful Data and Technical Leadership.

Popular belief about entropy leaves no room for interpretations: the bigger the entropy the greater the chance for disorder and chaos to lurk their ugly heads at every step. This means unpredictability, which of course is not amongst the desired qualities of a good design. However, as we shall see in a minute, big entropy (I am referring here to Shannon entropy not the thermodynamics version, although there are similarities) is not a quality of bad design, in fact we are not able to say anything more about a design by looking at its overall entropy than that it solves a certain problem which needs that many states as the design allows.

Alan Perlis once said A language that doesn’t affect the way you think about programming, is not worth knowing. Judging by the number of Stack Overflow questions and the impressive number of articles and posts on reddit, Slashdot or blogs, it is clear that the Haskell language deserves to be known. In fact, functional programming is indeed a domain which every hacker should be accustomed with.

Modern dynamics of software development with focus on frequent deliveries of working code makes performance an often overlooked aspect. Although approaches such as “Make it work first and refactor it later” have demonstrated advantages like easy and quick adaptation to changes of requirements, they often open the door to poorly written routines that affect performance in a negative way. Whether included in the development cycle from the very beginning, or caused by circumstances such as the discovery of very slow operation or abrupt performance degradation in certain scenarios (e.g. increasing the number of entry points such as the number of users that use a system etc.) or as a step prior to a scalability task, the measurement of application performance is a very important step in the lifetime of an application.