spinu.ro

Despre asta am vorbit astazi la RoCS2008 .

A fost o conferinta foarte interesanta, mai ales prin prisma faptului ca a adunat la o singura masa tehnologii care conteaza in zona web 2.0

In zona de tehnologie, au vorbit Boby Voicu despre API-uri si tehnologii Yahoo, Todi despre Silverlight si implicarea Microsoft in zona startups, Mihai despre Adobe, si eu despre abordarea Google.

Despre retele sociale a vorbit Justin iar Aura a prezentat Bucuresti Virtual in lumea Second Life.

Maine, intre 9:30 si 13:45 va astept Radisson SAS Hotel - Bucuresti ca sa discutam despre tehnologii web 2.0. Vor vorbi Boby Voicu despre tehnologiile Yahoo, Mihai Pricope despre Adobe, Todi Pruteanu despre Microsoft, si eu despre Google.

Agenda completa a zilei de maine este disponibila aici , inca va puteti inscrie (fara bani ) pe site-ul conferintei

Ne vedem maine ?

My father once told me about a nice way to design the alleys in a park. Simply leave the place completely unmarked for a month and after that, just create your official plans by charting the paths the people have already choosen. This way, you can be sure that you have the best design. It’s as simple ! BTW, my father is building houses, parks and roads for 35 years for now .

I remembered the story while reading this Gustavo Duarte post.

Some things I enjoyed :

• “optimize experimentation and improve feedback from reality“
• “the most important realities are user experience and technical quality“
• “…rigid upfront design is a sure way to a crappy code base or engineering disasters”
• “Have a bias for experiment over analysis, though both have their place.”
• “Optimize experiments: make them as early, fast, cheap, and broad as you can.”
• “Experiment vigorously.“
• “React to feedback. Let reality drive.“

OK, I’m doing exclusively Java for some years, so I might not be quite objective. I don’t have field experience with other languages than Java, so I might miss important stuff. Feel free to correct me, if so.

The question : “As a software company manager, or as an independent developer, would I make more money with static or dynamic typing languages ?“. OK, the correct question is “which approach would provide a greater productivity for my programmers ?”, but admit it, it’s catchy to talk about “the money” (you just have to admit that the money you gain depends only on your productivity) .

Now, some definitions from wikipedia :

static typing : A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Examples include Java, C, C#, Haskel.

dynamic typing : A programming language is said to use dynamic typing when type checking is performed during run-time (also known as “late-binding”) as opposed to compile-time. Examples include Perl, Python, and Lisp, Ruby, Groovy.

And one assumption :

• the most important thing about a specific programming language is the “time to the market”. The time from the point where the customer is coming to me, up to the point where I deliver him with a correct working implementation, that’s the criteria I will choose one programming language or another. Of course, you will tell me about easiness to change the code later, but I’d say it’s already covered (if it’s fast to develop correct code, than most probably it will be simple to change).

Seems that there is an increasing interest around dynamic typing languages.

So, state of fact, I have to admit that dynamic typing would make me more proficient (because otherwise, nobody would use the dynamic approach, right ? ).

Now, I’m trying to understand that (remember, I’m doing Java, so by nature I find it very natural to use static typing). Dynamic typing allows me to write less code (some people, I don’t remember the link, is talking about 40% - 60 % less code). At the same time, it does move some errors from compile time to execution time. Execution time errors that are harder to find. I have to test all the possible paths for a program to find them all.

Bruce Eckel says that if you do automated testing, you have everything under control, and you don’t really need the safety of the compiler for your code not to fail at runtime. There is another guy here who has the same view. I am doing automated testing for some time. But I don’t think I will every be able to cover all paths in the code I write. There will always be things I’ve never exercised in my tests. Can I afford the program to crash with some stupid “the method is not there” error after I’ve delivered (while knowing that it would have been so simple to catch the error even at compile time) ?

Honest answer, I don’t know. Based on the experience I have till now (remember, Java only), I would say that I prefer to write 50% more code for the sake of things being clearly defined in the first place, and have everything fail often. Or maybe the fact that you don’t have to care about interfaces and stuff makes your life so easy that you can really devote more time to solving the problem and writing tests.

I guess I’ll just have to try for myself…

Via Vali, un mini-ghid de SEO .

De pe amazon.com :

“Amazon SimpleDB is a web service for running queries on structured data in real time“

adica,

• ei (Amazon) gestioneaza serverul de baze de date

• tu iti faci un cont la ei, si folosesti un serviciu web ca sa rulezi query-uri SQL pe baza ta de date proprie

• platesti doar pentru cat utilizezi (cost compus din machine hour + data transfer + data storage )

Solutia este integrata cu Amazon EC2 si Amazon S3. Conform Amazon, este posibil sa folosesti puterea de procesare din EC2 ca sa rulezi algoritmi care folosesc SimpleDB ca sa ruleze query-uri, care query-uri intorc pointeri catre obiecte stocate in S3…niceee…

Adica…de ce nu aplicatii thick ruland pe client, folosind in spate SimpleDB ca server de baze de date, si eventual Amazon S3 ca sa stocheze fisiere si multimedia ?

De exemplu, aplicatii colaborative ruland in Android si folosind SimpleDB ca baza de date.

Sau, aplicatii Java pe client, pornite cu Java Web Start, cu SimpleDB in spate…mi se pare chiar frumos.
Organizarea informatiei difera putin de un RDBMS clasic.

Top-level ai “domains“, intr-un domain ai mai multe “items“, iar un item contine mai multe perechi cheie-valoare.

De exemplu, domeniul “angajati”, cu items-urile “gica”, “vasile” si “petrica”, fiecare item avand asociate valori :

gica : salariu=400, birou=3
vasile : salariu=200, birou=2, nume_pisica1=pisi1, nume_catel2=catelu23

Diferenta fata de modelul clasic apare prin faptul ca poti stoca ce chei vrei tu pentru fiecare item (dispare notiunea de ‘table schema‘).