Archive Page 2
F# – not on german keyboards
Whoever designed F# did certainly not have a german programmer in mind. Or how would you explain this
(* Print even fibs *)
[1 .. 10]
|> List.map fib
|> List.filter (fun n -> (n mod 2) = 0)
|> printlist
The pipe on a German Mac keyboard is <Alt> + <7>, which in itself ok; but directly followed by a ‘>’ – which is &ShiftAlt> + <the key right next to <shift> is absolute nightmare for anyone with delicate bones in the left wrist. RSS: you nearly got me, but I still prefer other functional languages.
Filed under: Uncategorized | Leave a Comment
Long time no read, I know. Well, I have been away.
Anyways, while I am not back yet, I stumbled across something that made me wonder: consider this:
class X
def self.a
def self.b; "b"; end
b()
end
def self.x
b
end
end
The ruby feature which allows you to define a function within another function is relatively new to me. Since I found out about it I used it to split a function into several parts but not to publish the parts in any namespace accessible from the outside, i.e. the parts should be accessible only from within the method.
Turns out that I was wrong. Apparently a “not-really inner function” is defined at whatever outer level exists (hence the need for the “self” part in “def self.b; …; end” in the example above). The method “b” is defined on the X class object, i.e. as if was written
class X
def self.b; "b"; end
def self.a; b(); end
end
Seems I will stop using that idiom.
Filed under: Uncategorized | 3 Comments
0×1e – Components, revisited
Lately I started looking into components again. What appealed me is that they could provide a uniform interface to parts of an application, rendering and all included. And the way they are were built into Rails they even spoke HTTP right out of the box.
Think about the possibilities! Using components you could move caching out of the application, getting rid of ridicously hard to maintain cache sweepers, and use well-established HTTP caching proxies. Using components you could easily have parts of a page delivered via an AJAX request, speeding up the initial response to the user! Using components you could distribute rendering between different application instances, and actually start using these multiple cores in your server’s CPU!
But wait! “Components”?
I really like what DHH said in the above link: “The problem with components is that they’ve never actually been in style. We just forgot to tell people that. Our bad, now being rectified.” So, for starters, they were never popular.
The other main reason is that Railers who have implemented components are noticing themselves refactoring away from them. It’s becoming clear that, in most circumstances, plugins or helpers or possibly even an engine would serve an application better than components.
Lastly, they’re slow. Blecchhh. That’s a show-stopper.
(Shamelessly cited from mysterycoder.)
Well, DHH has some style in saying some things. However, there are some compelling reasons to use components in the first place: whenever you are about to do a dashboard like page. I have never seen some code that does this in a clean and dry way and is efficient at the same time. And with the other goodies that we could throw in (see above)…
But here are some good news: at least the speed issue is not really a speed issue anymore. I tested a do-nearly-nothing application, with only a few before_filters thrown in for amusement. This is the controller portion:
def test1; render :layout => false;end
def test2; render :layout => false;end
def innard; render :partial => "innard";end
and the html templates are along the lines of
hi from <%= __FILE__ %>
<%= render :partial => "innard" %>
hi from <%= __FILE__ %>
<%= render_component :action => "innard" %>
With this setup I measured using “ab” against a single mongrel serving the pages, and I found the “test1″ testcase, i.e. without components, to be delivered in 24 ms. This includes the network overhead; rails logs the response time to be 6 msecs. The render times when using components is 30 msecs (12 msecs on the Rails side only.) While 6ms vs. 12 ms sounds like only half the speed, this is for more or less empty actions. The plain difference would still be 6 ms: on any real action this should not be that much of an issue. If it was, you shouldn’t use rails in the first place but look into Merb or Metal instead. Right?
Filed under: Uncategorized | Leave a Comment
Tags: 1rad, components, distribute, performance, rails, xc2
hot, hot, hot!
While it is rapidly becoming summer these days we are working on a really really fabtastic idea. Having said that: it is not the idea we are working on, the idea is already 90% feature complete. It is the prototype which is slowly growing.
Stay tuned!
Filed under: Uncategorized | Leave a Comment
Tags: rails, veezle.com
For all of you that are trying to install git-svn on your machine: Quite a while ago the git folks reorganized the command line interface, and what used to be called “git-<whatever>” is now called “git <whatever>” . Note the subtle difference here? So if you are looking for the git-svn binary on your machine: there is none.
git-svn is still part of the git-core. Chances are it is installed on your machine alongside git. If not, and you are on a Mac, you install it via “port install git +svn”
It is as easy as this, and it took me hours to find out. Someone should have said this, and someone who said it should have received a better Google ranking.
Filed under: 1rad, ruby | Leave a Comment
Tags: Bummer, git, git-svn, OSX
Skype? A nazi company?
Or how would you explain the skinhead with a pitbull doing a nazi salute, when entering
(toivo)
in a chat?
Filed under: Uncategorized | 2 Comments
Server problems
“Sehr geehrter Herr NN,
der CPU-Lüfter hatte sich aus der Halterung gelöst und war nicht mehr auf der CPU,
dadurch ist der Server abgestürzt. Ich habe nun alles wieder richtig befestigt,
die Probleme sollten damit behoben sein.
Mit freundlichen Grüßen”
Filed under: Uncategorized | Leave a Comment
Rails dynamic streaming doesn’t work. At least sometimes. While the Rails documentation, and all the euphoric comments in the community feature code examples along the lines of
# Renders "Hello from code!"
render :text => proc { |response, output|
output.write("Hello from code!") }
But this just doesn’t work as not-really-advertised. The reason? While rails correctly – that is to say in the way it is documented – does write directly to the output stream, at least with Mongrel the output stream is just a String.
So whatever you are doing: the entire request is still collected in RAM. Bummer!<
Filed under: Uncategorized | Leave a Comment
Tags: Bummer, rails, streaming
This is the third and final part of a series about Erlang.
Erlang/OTP didn’t come out of thin air. Quite the opposite – seldom you see a language and a platform where the implementation mirrors the intention that closely.
Lists, Strings, Binaries, Tuples: what is what and why?
A tuple is one strange creature: you cannot append to a tuple, you cannot loop through a tuple – all these things you can do with lists. So why do they exist in the first place?
There is something good about tuples: tuples – being of a fixed size – can be implemented in a super-efficient manner, being memory-efficient and providing fixed-time random access at the same time. Lists, on the other hand, are neither of both. For efficient encoding, decoding and parsing of messages that need structured data in some way you should always use tuples and nothing else.
So then why using lists in so many other places? Well, for most of the issues you don’t need fixed-time random access, but a structure, which can be enumerated and that can grow quite fast. And yes, this is your list. And finally, asking why a language stemming from a LISP heritage would have lists is like asking why the milkman is selling this white stuff :)
But even though you can do many things without fixed-time random access, there is still an important area where you just cannot do that efficiently, and this is string processing. Erlang implements strings as a lists of bytes (or byte blocks), and this cannot be done efficiently: to find out whether a pathname ends in, say, “.html” the platform has to scan to the end of the list and to look and see just then. Other implementations have to do the same, but they are faster in finding the end: an implementation with ASCIIZ-strings (i.e. C-style) looks for the first NUL-byte in the data – something that todays and even yesterdays CPUs support out-of-the-box, and PASCAL-type strings (i.e. length byte(s) + data) just add the length offset to the start address of the memory buffer.
Where are my objects?
The guys inventing Erlang/OTP wanted one feature, which is “live updates”. That means you can just update the erlang code of some part, and all new processes that need that piece of code start using the updated code right away. As a Rails developer you feel reminded of Rails’ development mode; but this time it is done in the language and is done right. What sounds like magic is, in fact, pure technology. Unices do the same all the time with dynamically linked applications: when you deploy a new version of, say, libc on your system all new processes start to use that version; while all the old processes still run with the old version of the library. No reboot required. (By the way, Windows doesn’t do that: a Windows system locks all .DLLs in use and prevents them from being replaced. Hence the need for a reboot when updating.)
Now you might ask: what happens to the data? When do you migrate old-version data to new-version data? This is something that you have to do yourself, if you need it. Better you don’t have incompatible changes to your data – Erlang doesn’t help you with that. But the same is true for the code itself. A change from, say,
fun(Opt)
case Opt of
stop -> do_stop()
end.
to
fun(Opt)
case Opt of
finish -> do_stop()
end.
could break the application. Live updates have to rely on code that is compatible to previous versions in terms of the API and of Data.
What has this to do with Objects? In a narrow sense this is totally unrelated. However, objects in an OOP implementation no longer expose the public interface only. To allow for inheritance the objects must expose its “protected” interfaces (i.e. every method that can be called from a related object) and all methods that can potentially be overridden in a derived class. These massively blows up the size of the application interface. Which makes an incompatible change more likely. Which breaks live updates. Case closed. (And hey: while OOP is nice to have, it is never strictly needed, right?)
Final Disclaimer
Opposed to Erlang/OTP this article does come out of thin air, sort of. I am no authoritative source regarding the history of Erlang/OTP, and as I never intended to be one. I do, however, like the intellectual exercise to ask not only the how, but the why, the when, and by whom too.
Filed under: Uncategorized | 2 Comments
Tags: Erlang
Bummer
~ > rake
(in /Users/eno/)
Rails requires RubyGems >= 1.3.1 (you have 1.3.0). Please `gem update --system` and try again.
~ > gem update --system
Updating RubyGems
Nothing to update
~ > gem -v
1.3.1
Filed under: Uncategorized | Leave a Comment
Tags: Bummer
