Posted: March 31st, 2008 | Author: lrei | Filed under: Uncategorized | Tags: html, Internet, ruby, Software, Tech, Ui | Comments Off
Dave Winer recently broke the news that Google will soon introduce a “Google Web Services”, a competitor to Amazon Web Services. This isn’t much of a shock to anyone. The extra bit that is somewhat of a surprise is the price: free. He then explains that the reason it will be free is that they can pay for it in the reduced cost of integrating new acquisitions into their infrastructures which would become, effectively zero.
I don’t agree with that. At least I don’t think that is the main reason. I think it’s just the same old business model – basic service is free, premium is paid. The same model you see in Google Apps and a lot of other business on the web.
The basic service will be limited, in terms of traffic and/or storage (file and DB) etc. This will be the most widely used by startups. The premium service will just be the same pricing model amazon – pay as you go, the only different is that you don’t start paying at zero usage but rather at a higher threshold. When a startup becomes successful its needs will grow exponentially. They will be using more than the maximum allowed for free, and they’ll need to pay. But that’s alright because now that they are successful they can afford it. And the 1% or so that will be successful will have subsidized everyone that didn’t make it and still give Google a nice profit. Let’s not forget that Google’s infrastructure is already here and even tens of thousands of failed ventures won’t make a dent in it. Successful ventures will generate enough cash to upgrade that same infrastructure. Specially as the cost of hardware continues to drop.
Off course I’m sure people at Google also thought of the acquisition factor. Past acquisitions have taken a lot of time to be integrated. I think it took something like a year for writely to become “Google Docs“. That’s a very long time on the web.
Combine the free GWS with the powerful web development frameworks like Ruby on Rails that allow single individuals to create useful applications quickly and the new marketting oppurtunities that the web2.0 has created and the cost of trying won’t be measured in millions, thousands or even hundreds of dollars. It will be measured in terms of hours – the hours you “wasted” trying. And that, in many cases, won’t even be “time wasted” but rather “experience gained”.
It’s a brave new world indeed.
Posted: March 25th, 2008 | Author: lrei | Filed under: Programming, Python | Tags: Entertainment, Programming, Python, ruby, Youtube | 6 Comments »
I just got an email (via the faculty-wide spam network) about the ACM International Collegiate Programming Contest (ICP) or more precisely about SWERC 08. For a few moments I thought “hey, this might be fun”. A second later I read something like
“Languages allowed: C, C++, Java or Pascal”
Yay it’s 1995 again!!!
Pascal? Didn’t Pascal die like more than a decade ago?
C++ and Java are so 90’s… where are the cool languages? Python? Ruby? Heck even Erlang and Haskell?
Considering the “retro” theme, I would’ve was expecting Lisp and Fortran to be in there. (Not (that I have anything against (lisp))).
So basically the point of the contest is seeing how well you do with a handicap? Kinda like the Olympic 100m with a broken leg (or 2 if you’re using C)?
Sounds very interesting but I rather go cut myself with the portuguese tokio hotel fans (via Tiago Farrajota)…
Posted: November 12th, 2007 | Author: lrei | Filed under: Uncategorized | Tags: Chefax, django, html, linux, News, ruby, Software, ubuntu | Comments Off
If you’re like me and don’t like having to install all that stuff in every PC you use than this virtual appliance is for you.
Or
If you want to start learning PHP/Ruby on Rails/Django _now_ instead of having to install/configure stuff.
Or
If you’re going to something like Sapo Codebits and want to take the server with you
Hightlights: LAMP (Linux Apache MySQL PHP), Ruby on Rails, Django
UbuntuWebServer Project
Virtual Appliance Market
VMWare Player (Free)
Posted: August 29th, 2006 | Author: lrei | Filed under: Programming | Tags: html, Programming, ruby, Ui | Comments Off
One of my favorite blogs just published a new essay All Aboard The Gravy Train:
Recently, some of the loudest rumblings have been coming from that quarter who current fascination is the scripting language Ruby, and its ORM library Rails. Think back to the last cycle of hype you saw in our industry, perhaps the Extreme Programming craze, and you’ll recognize many of the phenomena from that little reality excursion now reoccurring in the context of Rubyism. There are wild and unverifiable claims of improved productivity amidst the breathless ravings of fan boys declaring how cool it all is. There are comparisons against precursor technologies that highlight faults that are apparently obvious in hindsight, but which were significantly absent while those technologies were in fashion. And above all there is the frenetic scrambling of the “me too” crowd, rushing to see what the fuss is all about, desperately afraid that the bandwagon will pass them by, leaving them stranded in Dullsville, where nothing is cool and unemployment is at a record high.
It’s good to know that I’m not the only one out there with doubts about the quality of the software written by the jump-on-the-latest-bandwagon croud.
I’d just like to add one related comment: regardless of what the proponents of a certain programming language may tell you, you are not going to learn that language in 1 day, 1 week or even 1 month. It’s going to take you many years to be able to write reliable, secure, easy to maintain code with some speed. It will require a significant investment of time. Learning everything as you go is not sound software engineering. And also, the number of programming languages someone knows is not a good metric for how good of a programmer that person is.
Links:
Brooks’ No Silver Bullet or the entire The Mythical Man-Month.
Update (humorous): I just logged in to my desktop PC. Today’s fortune:
There are two ways to write error-free programs; only the third one works.
Posted: June 26th, 2006 | Author: lrei | Filed under: Programming, Security | Tags: html, Programming, ruby, Security | Comments Off
I broke into uncontrollable laugher after I read this post (via Halvar Flake). I was like “ROTFLOL! DUMBASS!”. Than after I finally stopped laughing I realized that the guy that made the post is not only an experienced programmer but also apparently a researcher? How can anyone be a C programmer for years (hell, even for months) and not know this? This left me wondering if this guy is the rule (average joe programmer) instead of the exception (dumb harry programmer). That made me sad.
While on the subject of programming and security I have to say I really like microsoft’s work on Spec# (and its derivative Sing#). Which is not surprising considering I’m a C# fan. I also liked the little I’ve read about Singularity so far but that’s subject for another post.
The fact of the matter is that while integer overflows like the one in the one in that google research blog post are trivial and easy to spot, others aren’t. Often functions can get passed values which they shouldn’t be able to get. This happens either because of some weird error in the program or because someone found a way to manipulate the values that get passed to that function. A simple example is when a programmer takes a “length” value written into a network packet by the client software and uses it to allocate memory on the server without making any checks.
Doesn’t take a genius to figure out that this isn’t a good idea. However as software complexity increases, situations like this can become harder to detect when the function that, keeping with the example, allocates the memory is thousands of code lines away from the function that processed the input in a different source file, written by other programmers, maybe years apart. Not to mention that if programmers are being told to work 12 hour days, 6 days per week to meet impossible deadlines set by incompetent people in management, the likelihood of something like this happening increases even if the programmers in questions would normally be very careful about flaws like these. When you’re exhausted and being pressured by your boss to code faster you tend not to care about “little things” nearly as much (and also make more mistakes, which leads to more frustration which leads to more “not caring”). Overworking programmers IS NOT A GOOD IDEA! Writing good code can be a very demanding task (especially in error-prone languages like C). And off course all programmers re-use code (functions, objects,…). A particular piece of code that used to be in a situation where it’s arguments were safe may find it’s way into a program where its arguments are unchecked user input (or something equally as bad).
Even if without any malicious intent, untested boundary cases, such as a function getting passed “buf_size” when it should be “buf_size-1″ can easily lead to crashes, data corruption or both.
As a programmer I’ve had to deal with these problems. Here’s how I write a function (pseudo c-code):
/* func
* Does [whatever was specified]
* Arguments:
* – unsigned int length – size of the thing. Must be at least MIN_LENGTH; Must be at most MAX_LENGTH.
* – Thing *th – pointer to the Thing.
* Returns: 0, ERR_OUT_OF_BOUNDS, ERR_INVALID_PTR, ERR_PRINTER_ON_FIRE.
*/
int func(unsigned int length, Thing *th) {
Thing tmp;
/* other variable declarations */
if ((length = MAX_LENGTH))
return ERR_OUT_OF_BOUNDS;
/* more code goes here */
/* This isn’t actual C code but you get the point */
if (tmp.values != values_that_make_sense)
return ERR_PRINTER_ON_FIRE; /* I don’t actually use this one and I always try to avoid generic error messages */
*th = tmp;
return 0; /* Everything went right as far as we know */
}
Then I call the function like this for example:
err = func(length, &th);
if (err != 0) {
check_for_every_possible_error_and_do_what_needs_to_be_done;
}
Basically my function checks a precondition and a postcondition. I could check the postcondition after the function but I believe a function should be as “self-sufficient” (and if possible, just depend on its arguments) as possible to ensure portability and prevent slipups. That way I can just copy the function, set the constants it uses and make sure I handle every error. Both the constants and the possible errors are listed in the initial comment which makes it easy to re-implement the function in another program.
Sure this is a poor man’s basic implementation of design by contract. If you’re interested in doing it in C you should probably look here. Personally I hope I’m done with C (and C++ and if it’s not too much to ask – it probably is – Java… I hate Java so very much). Regardless of what someone might tell you, creating reliable, secure code in C is a pita. Pointers and manual memory manual memory management are things of the past. The future belongs to managed code, garbage collectors, design by contract and generally speaking, higher abstraction.