Rebar poor proxy git fixer

Sometimes you are behind a http proxy, and the git:// protocol is not accessible.

For instance on erlang rebar, all developers  prefer the git:// protocol when listing dependency.
But how to fix it if you are behind a http proxy?

Ask help to git…

git config --global url.https://github.com/.insteadOf git://github.com/

Credits: http://erlang.org/pipermail/erlang-questions/2014-March/078402.html

iPhone: tornare indietro a iPhoneOS 3….

Se siete i fortunati possessori di un iPhone 3G “standard”, vi sarete accorti che ilnuovo iOS4 è lentissimo.

Personalmente la redazione di Gioorgi aspetta la prima patch fix, che speriamo riduca i problemi.

Per chi non può proprio aspettare, abbiamo scovato una procedura in rete per tornare indietro a iPhone 3; attenzione però perché dovete prima tenervi stretto un backup del sistema 3.x, per cui fatelo solo se siete pronti a correre qualche rischio (tipo, perdere i vostr high scores su qualche gioco)

Site redesign

This article has been retained for hisorical reasons. In this article we refers to blog.Objectsroot.com a site discontinued on August 2008

After some time, I have decided to start redesigning the content and the look of ObjectsRoot.com
I have slightly reduced the tags section, over-simplifying the access to my huge set of articles. With over 100 posts, there is no need of so much tags.
The search engine will help you to find old articles: do not worry anyway, permalinks will remain valid for a long time!

For a short introduction to the new site look, follow this link

In the next weeks you will see a new site look too, clean and clever… like no one before. Stay tuned!
Updated 14 May 2008: Site redesign is in progress. You will find the new site for the 23th of May. Comments are always wellcome!

Updated 21 may 2008: The basic look is finalized, and will not change.

Updated 6 June 2008: Suggested resolution is 1024×768 or higher. The page is dynamically rendered, anyway an 800×600 resolution is discuraged. Fixed some broken links

Javascript and Smalltalk

There is a future for SmallTalk? I was a very strong fan of the SmallTalk language, but in the last five years I have seen more and more contraction of its usage in the IT field.

The OLPC project, which uses also Squeak Smalltalk and its done by the core team fo Squeak, is not going very well.

Anyway, Dan Ingalls, one of the father of Smalltalk, is working on a new project called Lively. It is a rewrite of Morphic in Javascript, especially target  for building a Squeak-like interface.

 The interesting part of this work is a paper outlining the limitation of javascript as programming language. I have tried in the past years to look for ajax and or web 2.0 javascript libraries, but I feel very difficult to develop with them.

From the Paper we underline these parts:

Loading multiple JavaScript applications into the same virtual machine is problematic.[…] For instance, if two programs
happen to use the same names for global variables or functions, the overlapping variables or functions of
the first program will be replaced with the corresponding features of the second program, resulting in
unexpected behavior in the subsequent execution of the first program. Since JavaScript will not typically
give any warning messages or errors in such situations, the resulting behavior can sometimes be a total
surprise; in many cases the errors resulting from such situations may not be discovered until much later.

 

Evolutionary development approach is a necessity. Due to the highly permissive, error-tolerant nature of
JavaScript, JavaScript programming requires an incremental, evolutionary software development
approach. Since errors are reported much later than usual, by the time an error is reported it is often
surprisingly difficult to pinpoint the original location of the error. Error detection is made harder by the
dynamic nature of JavaScript, for instance, by the possibility to change some of the system features on
the fly.

 

A lot of room is left in optimizing JavaScript performance. Current JavaScript virtual machines are
unnecessarily slow. Even though JavaScript is a significantly more dynamic language than, for instance,
the Java programming language, there is no fundamental reason for JavaScript VMs to run two orders of
magnitude slower than Java virtual machines.

 

Memory management capabilities of the current JavaScript VMs are poorly suited to large, long-running
applications. Current JavaScript virtual machines have simple, 1970's style garbage collectors

 The reason of these issue are simple:JavaScript was intially a language for web developers, small and easy to use, and very compact.
Absence of errors or warning is a nightmare, if you care of your digitating time.
And Javascript is slow because no one will write  long script with it.

A very compact and clean discussion can be found in http://javascript.crockford.com/javascript.html 

Fixing these problems is hard. Until the current  implementation will not provide a better way of error detection, writing javascript code will be a very long and time-consuming task.

And using a so old garbage collector, give a chance to a c/64 BasicV2 to beat your code:  you are awared, guys :)

Anyway, there is a good set of javascript libraries out of there (prototype and jquery, for instance but not only), so you should be quite happy 

 

 

 

Dynamic languages troubles

I have read http://www.manageability.org/blog/stuff/chandler-failure and I think it is very danger way of exposing concepts.

In the article pointed out, the quite dead Chandler project is compared to the multi-billion Eclipse project. And then a too easy analysis is done against dynamic languages, where Java is the absolute winner.

I will try to fix some of the things said there, and to add also my two cents here :)


 

First of all, I use Java a lot, but I am also a fan of dynamic languages. Every tool has its place in the world, and I will avoid some holy war here. 

Anyway, it is important to understand major differences between very distant projects.

 

First of all, Eclipse is a very huge project, developed by IBM and based from the beginning with a very strong hype on plugin modularization.

The effort pushed inside Eclipse is very huge and come also from the San Francisco Project. Other IDEs (like JBuilder and Together) stops fighting Eclipse years ago, and eventually failed even to sell their stuff.

 So there are no similar example to Eclipse in Python/Ruby/Perl world. Even in PHP is hard to find a so huge and well designed program. And the languge here is less important: a company big as IBM can also code in PL/I all its stuff, without so much pain :)

Second, PHP is very successful language, even if a bit too insecure, at the present time.

PHP Language has poor support for modules and so on, but project like Drupal, Joomla and other are full of plugins, quite easy to write.

RubyOnRails is falling down because nobody is understanding why PHP should be abandoned for Rails.

Java architectural model is very well written and Sun worked very hard to it. Java Hot Spot VM is derivered from the Self dynamic language,  and has inside technology difficult to develop in an open source project.

Surely Dynamic languages are strong when there is the one-man-band paradigm: sharing works in Smalltalk was  a bit complex in early days.

Put Perl, python and ruby have a strong modularization concepts, and so this issue is often solved.

I have tried Zope and I think it is weak because:

  • Zope is user is non-existent. Zope user is a super-skilled web master which wants a web CMS without writing so much code.
  • Zope product upgrade is a nightmare
  • A stuck Zope Product can destroy your work. So hosting Zope is a problem
  • A lot of Zope basic objects (like cache accelerators and so on) are poorly minded: they works only on RAM, and are not thinked well. Drupal 5 has more strong theory for this issue, and Drupal is poor PHP code.
  • Zope use a proprietary database, when a simple SQL database with a relational mapper can do the same thing…think twice before reinventing the wheel!
  • Every major Zope releases breaks a lot of the API. This is the most stupid thing you can do as open source developer.

Chandler failed because they tried a very difficult business: calendar software is a very difficult area to address. All operating system (including possibly C/64 :-) has now a huge set of Personal Information Manager software (PIM), and LDAP solves sharing issue for big companies

Even Ximian Evolution is near death.

And your bigger competitor is Microsoft Exchange and… yes… old Unix.

Dynamic lanuages has many lacks, and difficult refactoring is a problem but… remember frefactoring tools was INVENTED under SMALLTALK!

IT is a place where you must be careful… isn't it?