Tigers, and lions, and bears, oh my!

Shame on me. I had a mistake in my previous pos. Thanks to

xaprb for pointing this out.I misplaced quote marks in my second query.Instead of date BETWEEN '2008-01-01 12:00:00.000' AND '2008-01-14 12:00:00.000' AND accomodation=1 I wrote this: date BETWEEN '2008-01-01 12:00:00.000' AND '2008-01-14 12:00:00.000 AND accomodation=1' Note the last quote mark after accomodation=1:)

We're hiring now.The first line in job description reads: Good or excellent knowledge of PHPHere's what we get: "I've just started learning РНР...» Perhaps, we should've stated our requirements more clearly... Somehow... :)

As I promised here are my thoughts:1. First of all, pattern matching lets you describe what yo eed with little or no effort. For example, consider these rules:{field} {field, Func} {field, {'=', field2}} Frankly, I have a very vague idea how these could be matched using ifs only. I guess you would create a Rule class and inherit a slew of classes from it. Something like RuleField, RuleFunc, RuleOperator and so on. If you use pattern matching, however, the rules are easily parsed::%%{field} validate_rule({FieldName}) -> ok. %%{field, Func} validate_rule({FieldName, Func}) when is_function(Func) -> ok. %%{field, {'=', field2}} validate_rule({FieldName, {Operator, FieldName2}}) -> ok. Such ease, however, may bring (and it does bring me) to my second thought:2. WTF-ish code. The thought that you can easily slice through complex constructs makes you write before you think.In my case I knew what I wanted to pass to the function, but I had no idea what I expected the function to return. Ok, I've parsed the rules, what now?As a result, the first version of the function would return a deeply nested list of lists that looked something like this: [[Field, [Error1, Error2]], [Field2, [Error3, Error4]]] It took me two additional refactorings to make it return a properproplist.This same "wow, look at how I handle things!" approach resulted in an ugly preprocessing of results before I return these to the user: lists:filter( fun(Elem) -> case Elem of {} -> false; {_, []} -> false; _ -> true end end, lists:flatten(validate1(A, ValidationRules, []))) Yup. Get rid of those unwanted elements before the user sees them. Are you scared? I am. I m saddened as well :(Here's where my train of thoughts stops...

there it is.... quite unusual, but there is no way back...

I've decided to see whether all is as well with Erlang's bit syntax as advertised.. A friend of mine has been struggling with SOny's OMA format which is being used in Sony's players. The only feature this format has that distinguishes it from "normal" formats is its lack of documentation and whatever documentation there is differs significantly from whatever actual files have to offer :) There are some good folk out there and they've reverse engineered the format and wrote a Java program to maniplate it. The program is available here: http://dmitriid.com/files/projects/erlang/OMA.zip. The program is accompanied by documentation on Sony players' directory structure and, what's more important, on OM file format as well. You can see the OMA header format in this file: http://dmitriid.com/files/projects/erlang/OMA.html. It doesn't look to horrible, does it? Let's see how Erlang handles it. The first obstacle comes from the sample file that comes with the application (trunk/dist/OMGAUDIO/10F00/10000001.OMA). The spec says it has to start with "E" "A" "3" 3 0 0 0 0 17 76 "T" "I" "T" "2" 0 0 You wish. In reality it starts with "e" "a" "3" 3 0 0 0 0 17 "v" "G" "E" "O" "B" 0 0 And there's lots of info before we reach TIT2. Oh well, hex-editor to the rescue. The files does contain the tags shown in the spec. However, they are placed differently and there's a bunch of other, unknown tags. Whatever shall we do? I propose moving byte by byte until we reach tags that we know of or the end of the header. I'll tell you from the start that I cheated. I don't read the codec info from the header, I stop as soon as I reach "E" "A" "3" 2 0 60 ff ff So, the code Open the file and read data from it parse_header(File) -> case file:open(File, [read, binary, raw]) of {ok, S} -> {ok, Header} = file:pread(S, 0, 16#0c60), H = case read_header(Header) of error -> {error, invalid_header}; Data -> Data end, file:close(S), H; _ -> {error, file_cannot_be_opened} end. Well, that was easy. Open the file. Read it. Call internal read_header function to actuall parse the header and return the value that we receive from the function. The read_header function couldn't be simpler read_header(<<$e, $a, $3, Rest/binary>>) -> Data = decode_header(Rest, []), Data; read_header(_) -> error. It couldn't be simpler because of the pattern-match. If the chunk of data that comes in starts with "e" "a" "3" it's passed to the upper function. Otherwise, the lower function is called. The actual parsing is contained in several decode_header functions which parse a single tag at a time. Here' an example: % Title decode_header(<<$T, $I, $T, $2, _:2/binary, Var:2/integer-unit:8, _:4/binary, Rest/binary>>, L) -> TitleLength = Var - 2, <<Title:TitleLength/binary, Rest2/binary>> = Rest, decode_header(Rest2, [L|{title, Title}]); What happens here? Keep the spec before your eyes. Here we go. The song title is stored as follows T I T 2 0 0 Var1 Var1 0 0 2 TitleString where TitleString is [0x0 String]. That's exactly what we've specified in the pattern: T $T I $I T $T 2 $2 0 _:2/binary simply skip the two zeroes 0 Var1 Var:2/integer-unit:8 a number containd in two bytes Var1 0 _:4/binary simply skip 0 0 2 0 0 2 0 TitleString Rest/binary All we have to do now is get the title from Rest. Empirically I've guessed that the length of this title in our case is Var - 2. Having decided on that, we can get the title using pattern matching, again: TitleLength = Var - 2, <<Title:TitleLength/binary, Rest2/binary>> = Rest, This way all we have to do is to parse all the remaining tags according to the rules and test them against a real file. The real file may give us a headache because it doesn't confirm to the spec (albeit informal) and adds several new and unknown tags. That is why we need to augment decode_header with: decode_header(<<>>, L) -> L; decode_header(Bin, L) -> {_, NewBin} = split_binary(Bin, 1), decode_header(NewBin, L). We move forward byte by byte. If we match a known tag, it is caught by the corresponding decode_header. If we've reached the end of the header, this will be natched by decode_header(<<>>, L). Otherwise we move forward by one more byte and repeat the steps nce again. The entire file is available here: http://erltag.googlecode.com/svn/trunk/src/oma.erl. If you want to practice, download this file: http://erltag.googlecode.com/files/erltag-release.zip(6.1 MB). You can find the sample audiofile in the test folder. By the way. The code doesn't pretend to be the most effecient and correct way of writing Erlang code. Most likely the code is rather opposite of that :)

Past Friday I got myself acquainted to Python. Different people view Python as "nothing to learn" or as "if only I had time to learn" or even as "very difficult to learn". I had to learn it quick for a very simple reason. I have lots of photos taken at different resolutions. I need to resize them to different sizes (much like Flickr does), create several thumbnails of each image, upload them to a host (Amazon S3) and load information on uploaded images to a database. The process must be automated, of course. It all started when I convinced myself that Python Imaging Library is the best library to manipulate images. Indeed: import Image   im = Image.open('path/to/image') im.thumbnail((800, 800), Image.ANTIALIAS) im.save('path/to/image') The line with im.thumbnail((800, 800), Image.ANTIALIAS) is absolute genius. If your image is, say, 1024х768px, then what you get in the end is not a skewed 800х800px, but a proportional 800x600px. Combined with MySQLDb and Boto this yields a very easy solution to my task. However, that's not the point. As it turns out, getting to know many languages (even superficially) may give you a huge head start in learning a new programming language. I've had an overview or, sometimes, more than an overview of such languages as Lisp, Haskell, Erlang... How does that help me with Python? Well, I got an imeddiate understanding of the following: Note: I can bear no responsibility for Haskell codes in the examples :) Tuples and destructuring assignment A tuple is a fixed-length list. This list may contain elements that are very different in nature: # Python tuple (1, 2, 'hello') -- Haskell tuple (1, 2, "hello") %% Erlang tuple {1, 2, 'hello'} Looks similar, doesn't it? :) Let now get data out of our tuples: # Python # А will contain 1 # В will contain 2 # С will contain 'hello' A, B, C = (1, 2, 'hello') -- Haskell -- a will contain 1 -- b will contain 2 -- c will contain 'hello' (a, b, c) = (1, 2, "hello") %% Erlang %% А will contain 1 %% В will contain 2 %% С will contain 'hello' {A, B, C} = {1, 2, 'hello'} Certainly, the principles of theses examples are very different. Haskell and Erlang use pattern matching that Python doesn't have. However, it looks very similar and is very easy to understand once you know the other examples. PHP, by the way, has a similar thing: // А will contain 1 // В will contain 2 // С will contain 'hello' list($A, $B, $C) = array(1, 2, 'hello') This, of course, is very different and the inner workings are absolutely different :) One thing about this is quite peculiar, though. Once you get used to these sorts of destructuring assignments, you start using PHP's list and Python's tuples much more often. Because it's so convenient. Named parameters I once talked about named parameters. As it turns out, Pythons has them. # define a function def myfunc(param='', another_param=1)     print param, another_param     # call the function   # will print hello 5 myfunc(another_param=5, param='hello')   # will print hello 1 myfunc(param='hello')   # will print 1 myfunc() Anonymous functions (lambdas) # Python # define a list li = [1, 2, 3, 5, 9, 10, 256, -3]   # get only evens out of the list li_even = filter(lambda item: item % 2 == 0, li) Very similar to code in other languages: -- Haskell -- define a list li = [1, 2, 3, 5, 9, 10, 256, -3]   -- get only evens out of the list li_even = filter (\item -> (mod item 2) == 0) li %% Erlang %% define a list Li = [1, 2, 3, 5, 9, 10, 256, -3]   %% get only evens out of the list Li_even = lists:filter(fun(Item) -> Item rem 2 == 0 end, Li) List comprehensions Remember how we used to define lists in mathematics? For instance: S = [1, 2, 3, 4] M = {x | x in S, x even} M is all x's where x belongs to S and x is even. Nice languages have ways to define lists in a very mathematical way. This is called list comprehensions. One downside to Python's comprehensions is the syntax. Here are previous examples rewritten to use list comprehensions instead of lambdas: # Python # define a list li = [1, 2, 3, 5, 9, 10, 256, -3]   # get only evens out of the list li_even = [x for x in li if x % 2 == 0] -- Haskell -- define a list li = [1, 2, 3, 5, 9, 10, 256, -3]   -- get only evens out of the list li_even = [x | x <- li, (mod x 2) == 0] %% Erlang %% define a list Li = [1, 2, 3, 5, 9, 10, 256, -3]   %% get only evens out of the list Li_even = [X || X <- Li, X rem 2 == 0] Anyhow, thanks to other languages the new language (a more or less mainstream language, not K :)) ) is not just easy, it's extreamly easy and can be learned in, say, 15 minutes. Update: Corrections to Haskell code. Thanks,

deni_ok

HAPPY NEW YEAR TO ALL FRIENDS AND ENEMIES!!!

I'm still late on my promise to talk about pattern matching even though today's post is related to patern matching.In brief here is what pattern matching all about. The all-knowing Wikipedia defines pattern matching as   the act of checking for the presence of the constituents of rigidly specified pattern What does this mean though? This means that when a function (especially in dynamically typed languages) accepts parameters of different kinds/types we can define this function like this::   fun([H|T]) -> do_smth(); fun({a, tuple}) -> do_smth_else(); fun(value) -> do_a_third_thing(); fun(DefaultValue) -> do_default_thing(). What happens in the code above?  1. First function accepts a list/array as its parameter. The list consists of a Head and a Tail. So, if we pass [1, 2, 3, 4] to this function, the variable H will contain 1 and variable T will contain [2, 3, 4]2. The second function accepts a tuple, that consists of two immutable values, "a" and "tuple"3. The third function accepts an immutable value of "value"4. The fourth function accepts everything rejected by the first three functions So. If we call a function like this:   fun([2, 5, 72]). we will trigger the first function, since it accepts an array/list.However, if we call the function like so:    fun({another, tuple}). we will trigger the fourth function. Why? Because even though we pass a tuple, the third function accepts only one tuple, {a, tuple} whereas we pass a different tuple, {another, tuple}.So what's refactoring got to do with all this? And what's function guards?A couple of things about function guards. Consider the ubiquitous Fibonacci function. First, pattern matching:   fib(1) -> 1; fib(2) -> 1; fib(X) -> fib(X-1) + fib(X-2). Now, function guards:   fib(X) when X =< 3 -> 1; fib(X) -> fib(X-1) + fib(X-2). The first line reads: "If X is less than 3, return 1". Guards can check for a wide range of conditions, including such thnigs as is_list(X), is_tuple(X) etc. They can also be stacked using such keywords as "and", "or" etc. More on them in forecoming topics. Back to the topic at hand.A question was raised over at RSDN with regard to implementation of the Factory pattern. For instance, in creating a wrapper for various database connections. The following С++ code was given as an example:   class Driver { public: virtual void connect() = 0; }; class MysqlDriver : public Driver {}; //implements connect() using some mysql API calls. class OracleDriver : public Driver {}; //implements connect() using some oracle API calls. And, finally,    class DriverFactory { public: static Driver * createDriver( string name ) //creates necessary driver { Driver * driver = 0; if("mysql" == name ) driver = new MysqlDriver(); else if( "oracle" == name ) driver = OracleDriver(); else throw 1; return driver; } }; The key to this factory, is of course the following:   if("mysql" == name ) driver = new MysqlDriver(); else if( "oracle" == name ) driver = OracleDriver(); else throw 1; Ok. Let's rewrite it using Erlang.First that springs to mind is the obvious line-by-line translation of the C++ code:   start(Driver) -> case Driver of mysql -> % connection happens here {}; mnesia -> % connection happens here {}; odbc -> % connection happens here {} end. It's clear that you would call the function as follows:   start(mysql). start(mnesia). start(odbc). Note that the "case" construct in Erlang also employs pattern matching.What if connection i a bulky piece of code spanning 10-20 lines? We could employ function guards of course::   start(Driver) when Driver == mysql -> % connection happens here {}; start(Driver) when Driver == mnesia -> % connection happens here {}; start(Driver) when Driver == odbc -> % connection happens here {}. This is more like it. Function call hasn't chaned a bit: start(driver_name). Guards, however, are not expressive enough. You have to read the definition of the function and only after that your eye cathes the guard. Is there a better way to do this? Of course!Recall that pattern matching involves a "rigidly defined pattern". What's more rigid than   start(mysql) -> % connection happens here {}; start(mnesia) -> % connection happens here {}; start(odbc) -> % connection happens here {}; We can improve on our example and introduce options that will be passed to the connection code:   start(Driver) -> start(Driver, []). start(mysql, Options) -> % connection happens here {}; start(mnesia, Options) -> % connection happens here {}; start(odbc, Options) -> % connection happens here {}; start(_, _) -> {error, driver_not_supported}. Last lines simply states that for any other type of connection we through an error. Underscore means "any variable", a sort of "joker".That's a part of what, to me, is the "Erlang Way". Very shortly and quite inaccurately this could be defined as: focus on what you need. A slight improvement of this definition is described in the concept of "aggressve programming". See. Erlang programming rules for a description. That is, a program/module/function should do only the things it's meant to do. Under all other circumstances it should fail specifying why it failed, because it really should be the problem of the person who decided to (ab)use the program/module/function in the wrong way. As a result you end up with a small number of functions/modules which only do what they are meant to do. And this is quite handyThe same page lists other things in the "Erlang way", in particular:  - top-down programming (you start with abstractions and work towards details), - "make it work correctly now and worry about otimizations later", - principle of least astonishment (the system must behave predictably)- "aggressive" programming etc. Actually, this approach can be used - and is used! - in mainstream languages such as C++, Java, C#. However, in order to employ this approach in these languages, you need experience (quite a lot of it some times - a nod to C++). Erlang, on the other hand, encourages this approach right from the start.I general, I'm not going to give up on Erlang in the forseeable future :) Unless it's in favour of Ne,erle, perhaps :))

Camrade qrilka has shown interest in Orcas. Right now we are not quite sure as to what is the best approach to SOAP in Erlang.Since RSDN's webservice is quite small, one approach would be to implement all calls and parse all responses by hand. But that's boring, isn't it? :)Today I've braced myself and went to war with erlsoap, which has been stagnating for the past two years. Well, you can check out the code yourself. The file is test_soap.erl, and you run it by   test_soap:run(). qrilka suggested that we use Smerl. This still leaves quite a lot to do by hand. Anyway, tomorrow, time permitting, we'll take a look into the matter.

Kosma Prutkov. Fruits of thought. # 66Many a thing we do not understand not because our reasoning is weak, but because we have no notion of them

It is a major pain in the nether regions of the body to work with a language which provides reasonable tools for working with XML and provides no sane tools to modify XML. I'm talking about ColdFusion.Suppose we have the following piece of XML: <xml> <root> <elem> <value>Text</value> </elem> </root> If we read this piece into a variable called xmlDoc, we have immedate access to the value "Text": txt = xmlDoc.root.elem.value.xmlText; Now txt contains, as you may have guessed it, a string, "Text".Moreover, if we have quite a handful of such elements, we may use an extremely convenient function XMLSearch which accepts (an unspecified subset of) XPath and returns an array of found elements.A real-world example now. Here's a stripped-down localization file from the project I'm working on:: <?xml version="1.0" encoding="UTF-8"?> <strings> <nspace NAME="global"> <string CRC="73FB418E8CCD929E219338A555AA7EA4"> <original>You need to login first</original> <localized/> </string> <string CRC="99DEA78007133396A7B8ED70578AC6AE"> <original>Login</original> <localized/> </string> </nspace> <controller NAME="admin"> <action NAME="cities"> <string CRC="FD8459135F9464065B708800B0BDF6D8"> <original>Add a new city</original> <localized/> </string> <string CRC="F67FDD86A499050E0585BCA9EA023188"> <original>Add city</original> <localized/> </string> <string CRC="4505DE1F3D02176AA6F1403778C5ADD1"> <original>Region:</original> <localized/> </string> </action> </controller> </strings> Searching across this monster of a file is trivial: searchString = "/strings/controller[@NAME=""admin""]/action[@NAME=""cities""]/string[@CRC=""CRC""]"; elems = XmlSearch(xmlDoc, searchString); /* If there's only one elems, we return it (simplified example): */ return elems[1].localized.xmlString; where CRC is calculated using obscure Vodoo rituals :)Now, the question is: what if we want to change the value oа this element? The procedure required to do that evokes an unbearable desire to nuke Macromedia offices :)Scanning thorugh the docs reveals that the only standard procedure to change the desired value of a tag involves the use of ArrayAppend function on the array of "value" from the array of "elem" from the array of "root"...That is... You can find an element, but you cannot manipulate it directly. You have to take the root element. Then you have to take an array of first-level elements anв find the desired one. In that element you once again take an array (of second-level elements) and find the desired one. In that element you take an array of third-level elements and find the desired one. And finally, you take an array of fourth-level elements and find the desired one. If such an element does not exist, you append it to the array of fourth-level elements. Save.Anyway, here's what it looks like in the end: // Add a new string ArrayAppend(xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].XmlChildren, XMLElemNew(xmlDoc, "string")); // Find its position stringIndex = ArrayLen(xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].XmlChildren); // Change its attribute xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].string[stringIndex].xmlAttributes.crc = Hash(t); // Add "original" to it ArrayAppend(xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].string[stringIndex].xmlChildren, XMLElemNew(xmlDoc, "original")); // Find original's position orgIndex = ArrayLen(xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].string[stringIndex].xmlChildren); // Add text xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].string[stringIndex].original.xmlText = t; // Add "localized" ArrayAppend(xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].string[stringIndex].xmlChildren, XMLElemNew(xmlDoc, "localized")); // Obtain its index locIndex = ArrayLen(xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].string[stringIndex].xmlChildren); // Add text xmlDoc.strings.xmlChildren[controllersIndex].action[actionsIndex].string[stringIndex].localized.xmlText = ''; :)))I am only grateful that I had to write this function only once. And it took me the better part of the day...

In July 2006 CNN Money gave a fellow named David Heinemeier Hansson the 50th place in their list of most influential people in contemporary online business (also known as Business 2.0).What? You don't know who this fellow is? Well, he is the creator of Ruby on Rails.Ruby on Rails is an iPod of online technologies: Like iPod, Rails doesn't use any new revolutionary technologies: - Ruby itself appeared in 1995 - The MVC (Model-View-Controller) pattern was first described back in 1979 and so on Both iPod and Rails, when they appeared, were the cause an unprecedented buzz and discussion. Rails's fans, much like iPod's fans, are blind to the shortcomings of their favorite toy and are ready to rip any critic to pieces (or worse). Rails, like iPod, has created numerous clones which are striving to duplicate the functionality without actually introducing any new ideas: - PHP: CakePHP and Zend Framework - ColdFusion: ColdFusion on Wheels - .NET: MonoRail - Perl has Catalyst, though this framewrok isn't originally based on Rails - Python has TurboGears, though its creator stated that this is not a Rails clone So, why Rails has not only appeared, but also become very popular and eagerly cloned?I suppose this happened because Rails (and iPod, too) showed us that technology can be humane. In the case of Rails you can obtain interesting result fast - lightning fast (nonbelievers can check out Rails screencasts). Most of the time you spend in Rails is not fighting databases, or sessions, or files, or anything else, but actually writing the logic of your application.Additionally, Rails lowers the entry level for the MVC pattern (quite a complex pattern, actually). You simply forget about it, it comes to you naturally.Rails is, in essence, a ready and sound foundation that let's you build your own house. You may choose either a number of available blocks or just build everything brick by brick. Most other framewroks, on the contrary, have been providing you with either a finished house or with a number of raw materials and a dozer.So, this David Heinemeier Hansson fella has again proved that no "designed by committee" system/framework (even if this committee is a multi-billion dollar corporation) can ever compete with frameworks that people build for themselves. After all, people know better about their own needs than a committe ever will.Anyway, I can't wait to see what happens to web technologies 5 years from now. After all, too many developers have accustomed themselves to thу idea of humane technology to ever turn back. I hope.

On the heels of the last post:Found here

Where else, other than in Web programming that is, can you find such a mash-up? :)