Well, hello hello...

In seara asta pe la ora 20 m-am decis ca ar fi o chestie sa incep sa postez o parte din gandurile mele, informatii si stiri pe care voi incerca sa le cometez, fotografii s.a.m.d, in mare sa imi dezvalui punctul de vedere vis-a-vis de lucrurile care ma/ne inconjoara in acest format, cel al unui blog.
Voi recunoste ca nu am fost spontan (asa cum am incercat sa dau impresia mai sus)> ideea de a avea un blog mi-a venit pe la inceputul verii insa nu i-am dat prea mare atentie pana acum. De ce acum? Pai, nici eu nu stiu insa nu cred ca e relevant... Cel putin pentru mine nu este.

Ok, gata cu introducerea (pfuu am scapat de ea)
Atat va mai spun: spor la citit si la comentat. Sper sa va placa si sper sa ma tin de chestia asta.

Pentru moment va las cu imaginea asta. O tin de mai bine de un an ca wallpaper pe telefon. Banuiesc ca imi place prea mult ca sa o schimb, atipic mie de altfel.

Ciao Ciao...

Git is MacGyver

Git's design philosophy is unmistakably that of Unix: unlike Subversion, CVS, or Mercurial, git is not one monolithic binary but a multitude of individual tools, ranging from high-level "porcelain" commands such as git-pull, git-merge, and git-checkout to low-level "plumbing" commands such as git-apply, git-hash-object and git-merge-file. So, like MacGyver, you can do just about anything you need with Git - this includes totally awesome Wiki engines, issue trackers, filesystems, sysadmin tools - everything short of fuse repair:

As such, git is not so much a version control system as it is a tool for building your own version-controlled workflow. For example, when faced with the fact that no git tool performs the equivalent of hg addremove - a useful Mercurial command that adds all untracked files and removes all missing files - I found one line to a script originally written by James Robey:


#!/usr/bin/env bash
# git-addremove
git add .
git ls-files -deleted | xargs git rm

Git's branching, tagging, merging, and rebasing are near flawless: git's merging algorithm is close to omniscient, having once merged 12 Linux kernel patches simultaneously. Additionally, git provides you with tools to go back in time and edit your commit history - useful for those of us who have left certain critical elements out of a commit and had to quickly recommit with a helpful message such as "oops". (And when I say "those of us", I mean "every developer, ever".) Personally, I elect to only use this feature to edit my last commit (using git commit --amend); I have never needed or wanted to meddle further with the past. git is also extremely fast thanks to its C codebase.

There is no better emblem of git's flexibility than GitHub. GitHub's rise to success has been positively meteoric, and with good reason. It's a brilliantly-designed site that serves as more than a pretty, browsable frontend to my source tree in that it brings a social aspect to programming - using Git, I can fork anyone's project, make my changes, petition for them to be included in the main repository, and pull other people's changes to mine. Though it took a while for me to adjust to the anarchic notion of every user having their own equally-valid fork of a project - shouldn't there be one definitive version of a project? - I realized its potential when working with other contributors to Nu. Add the fact that GitHub is one of the most solid and reliable services I've ever used, and you've got what very well might be the deal-breaker in the fight for DVCS dominance.

On the other hand, migrating from Subversion/CVS to git requires a lot of work. Linus has made it clear that he disagrees with the fundamental ideas behind Subversion/CVS, referring to SVN as "the most pointless project ever started". As such, the git project has consciously made no effort to make the migration to git easy: the revert command in Subversion resets your current working copy to the last commit, but in git undoes a supplied patch and commits the changes needed to remove that patch. (The equivalent command for svn revert in git is git reset --hard HEAD^.) Whining about this on the git mailing list is a little like this:

Get it? No? Too bad.

Apparently the choices that Linus et. al made when designing git are sensible - if, of course, you understand the internal structure of git and how it stores your data. I'm afraid I'm only halfway through PeepCode's great Git Internals, so I can't comment on whether that statement is true. But I have to admit that if I had to read a $9, 100-page PDF to learn every new tool I downloaded, I would have no time and no money.

This brings us to another of git's faults: its documentation is terrible. Man pages are no longer a sufficient replacement for a good, well-updated wiki or reference work; git's wiki still has a long, long way to go. Add in the fact that since, like many OS X users, I installed git through MacPorts, only the main git tool comes with a man page, leaving me to consult the Web to find out exactly how to format revision specifiers. I've observed that developers that were able to learn git from colleagues already familiar with git and its internals tend to have a higher opinion of it, in contrast to people such as myself that had to waste a lot of time digging around through Google and the man pages.

However, considering the fact that git is supposed to be a platform, one would suppose that it would have clear, bridgable functions to reuse in your own C projects and bridge to other languages. One would be completely wrong - libgit.a is a joke, and the Ruby git gem (and my own vastly-inferior Nu/Git bindings) depend on running shell commands and parsing the output, which really gets quite tiresome after a while. The fact that console output may differ from platform to platform and any new feature may change the format of console output makes me very reluctant to commit to maintaining my Nu/Git bridge. (I swear, that's the reason. It's not because I'm lazy.)

In conclusion, Git is perfect for command-line wizards, people with large teams and complicated projects, and those who need their DVCS to be endlessly configurable. Certain developers have a workflow which, when interrupted, causes much grief and lamentation - if that description fits you, then git is almost certainly what you want, because it can be molded to fit the most esoteric workflow. Solo developers and those accustomed to working with centralized VCS's may find git to be hostile, unfriendly and needlessly complex. When I work on a large project with many committers, I prefer git and GitHub.

Mercurial is James Bond

mercurial |mərˌkyoŏrēəl|
adjective
1) Subject to sudden or unpredictable changes of mood or mind: his mercurial temperament.

Though there have been many unfortunate open-source project names, Mercurial (also referred to by its command-line-tool name, hg) is both apt and unfortunate: though it is definitely speedy, both in terms of learning curve and execution speed, it is also at times inconsistent, maddening, and unpredictable. Mercurial is like James Bond: though they are not suited for each and every job, put them in a situation for which they are prepared and you will get things done. (If your programming job is as exciting as a Bond movie, please get in touch with me right away when one of your programmers is killed in action.)

In contrast to git's philosophy of providing a flexible platform built out of individual components, Mercurial is monolithic and (relatively) inflexible. Developers who like to keep their system clean will probably appreciate the fact that hg installs one binary in contrast to the 144 that make up git, and developers who think that git's ability to edit your previous commits is moronic, unnecessary, and dangerous will appreciate the simplicity hg provides by omitting that particular feature.

Compared to git, hg's branching, merging and tagging systems are equally powerful and only slightly slower. The only current flaw in Mercurial's branching system - and sweet crouching Jesus, is it ever a huge flaw - is that deleting named branches is unbelievably difficult: as far as I can tell, the only way to do so is to learn and enable the patch-queuing system (about which I have heard raves, but have not had the time yet to sit down and grok) and use the hg strip command, or install the local-branches extension. Selenium currently recommend you use tags instead of branches, which practically redefines the concept of a half-assed solution.

Despite that glaring flaw, the rest of hg is excellent. It functions almost identically to Subversion in the commands that it shares, and the new concepts - branching, merging, etc. - are easily learned and intuitive. Whereas I'm still learning how to do relatively basic things in git, I learned pretty much all of hg's functionality in about a day. If you're familiar with Subversion, transitioning to Mercurial should be a piece of cake - the functions you're familiar with will be there, and the new functions are easy-to-learn and well-documented.

Though I've never tried to integrate Mercurial's functionality into my own projects, I hear that since it's written in Python it's very easy just to import its classes and call them programatically rather than parse the output of shell scripts. I wanted to write a Mercurial frontend for OS X (I was planning to call it 'hermetic' - get the elaborate literary pun?), but the viral nature of the GPL discouraged me - since no company has granted me stock options for my code, I'm a little reluctant to just give away the fruits of my labors. Mercurial's answer to GitHub is BitBucket, which I have not tried yet. If I do, I will update this entry posthaste.

In conclusion, Mercurial is the yin to git's yang: those such as myself who are constantly experimenting with new ways to work and write code will object less to the restrictions that hg imposes on workflows. After switching to Mercurial for a small two-person project last year, my collaborator observed that Mercurial feels a lot more Mac-like - usability and smoothness of operation trump Unix philosophy when necessary. If I don't have to share my code with anyone, I tend to use Mercurial in order to get things done faster.

So, What's My Point?

To paraphrase Colin Wheeler, it's OK to proselytize to those who have not switched to a distrubuted VCS yet, but trying to convert a git user to Mercurial (or vice-versa) is a waste of everyone's time and energy. If you want to switch to a DVCS, then here are five easy steps:

1. Evaluate your workflow and decide which tool suits you best.
2. Learn how to use your chosen tool as well as you possibly can.
3. Help newbies to make the transition.
4. Shut up about the tools you use and write some code.

A quick look at the output of hg clone --help reveals the following:

• Running hg clone copies the tracked files and hard links the metadata (.hg directory).
• hg clone --pull copies everything and hard links nothing.
• cp -al copies nothing and hard links everything, which means your editor had better break hard links or else changes will be saved in two repositories at once.

In other words, an invocation of hg clone followed by editing some tracked files will always do the right thing, regardless of what your editor does.  Since I always clone repositories using hg clone (disk space isn't too tight at the moment), it was never an issue, even using a rather complex Java IDE.

That got me wondering, though, what would have happened if I cloned using cp -al. It turns out that by default,

• emacs breaks hard links.  Can be overridden by adding (setq backup-by-copying-when-linked t) to one's ".emacs" file.
• vim preserves hard links.  Can be overriden by set bkc=no in .vimrc or at the vim command line
• Eclipse preserves hard links.  This was tested empirically rather than looked up in documentation, and there isn't an easily-located setting to change this.
• OS X TextEdit breaks hard links.  Also tested, and I didn't even look for a way to change it.

The moral of the story:  when in doubt, hg clone.

trespassing within my complacency
my dull sanity

a piston pumping sexless intrusion

wasted words come all over the walls
a bouncing echo around this cell

a stray word flies off every angle
like a failed conversation, it keeps me flailing
reaching for some hint of me in all of this you

let me sacrifice to the altar of your ego

place your loving hands inside my growing need
and let chemistry feed this biology

we are no more than sitting ducks unfucking our attractions
stroking flaccid masterpieces just to feel the grip

Fortunately enough, X11 is a wonderful system. I can remap and swap keys to my heart's desire, and this is precisely what I did just a few minutes ago:

keramida@kobe:/home/keramida$ hg log -v -p -r tip
changeset:   145:a148a5c79c0e
tag:         tip
user:        Giorgos Keramidas
date:        Thu Jul 17 04:13:20 2008 +0300
files:       .Xmodmap
description:
xmodmap: Replace the "Windows" keys with Alt_L and Alt_R

A couple of extra `Meta' keys are more useful than the
completely useless "Windows" flaggy bits.

diff -r e34b7e6ea856 -r a148a5c79c0e .Xmodmap
--- a/.Xmodmap  Thu Jul 17 04:22:57 2008 +0300
+++ b/.Xmodmap  Thu Jul 17 04:13:20 2008 +0300
@@ -32,3 +32,15 @@
 keysym Caps_Lock = Control_L
 add Lock = Caps_Lock
 add Control = Control_L
+
+!
+! Customizations for Turbo-X laptop.
+!
+! Make the Windows keys act the same as ALT.  I don't really need an
+! extra pair of ALT keys, but my fingers hit Windows keys far too often
+! when I want to type meta-combos.  This makes the windows keys more
+! useful and my fingers more happy.
+!
+
+keycode 115 = Alt_L
+keycode 117 = Alt_R

keramida@kobe:/home/keramida$

Neat. Now I don't really care if my fingers slip and hit one of the "Windows flaggy bits". That's really really nice :-)

PS: In a followup post, when I catch up with $realwork I'll write more about the move from an old-ish, crashed laptop to another one. Let's just say, for now, that FreeSBIE saved the day!

Mercurial offers revision control for all types of files (text or "binary"), and allows users -- individually or in teams -- to clone a file set for copying or editing locally without interfering with others.  Further, users can seamlessly push and pull file changes between computers.  More officially stated, Mercurial is "a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects."

When hosted on a web server, Mercurial users can push and pull changes through that web server.  When a custom web server is not available, the site freeHg.org offers free public hosting thanks to Matthew Marshall.  I tried freeHg.org, and it could not be much simpler or easier to get started.  Thank you, Matthew!  I like your setup.

Alternatively, brave software developers can try hosting Mercurial on SourceForge.

Do you have questions about Mercurial?  Check out the homepage, the unofficial manual, or the FAQ.

Here's the plan of attack for the blog, it will essentially follow my development stream. I am going to try and keep a good log of each step of the development process as I go hopefully with daily updates.

As I learn the ins and outs of the iPhone platform I plan on firing out test level code for people who want to learn about game development and while the sample/test code will be iPhone specific the ideas will usually translate to other platforms.

[Note: I'll do my best to have copious comments but no promises ;)]

Day 1: 

Day one has actually been about 3 days but who's counting. ;)

The first thing I had to do was was tool selection and as I am coming to iPhone development from the world of Windows and J2ME I needed to do some research.

For hardware I've gone with the MacBook Air and I must say even though it's a tad overpriced based soley on hardware specifications it is well worth it...  I love this machine!

The developer tools I will be using are:

• Xcode (of course)
• TextMate for Editing
• Mercurial for Source Code Management
• KJam as the build tool and while I am a fan of KJam I am looking for a possible alternative to this excellent make utility

Now selecting core engines and such is a bit tricky, normally I'd write my own but given I am doing this as a one man band I have to use some tools that others have built. Of course I will be making mods as needed (and in the case of community developed tools I want to make these mods available).

Now physics, AI (such as pathfinding), object management and Collision Detection are pretty core to any game so selecting (or writing) the right engines is critical and this is where I will be starting.  

For the physics library: I am incredibly lucky (we all are) as there is a library called Chipmunk which is just awesome! Now Chipmunk handles rigid body physics and I need some additional things so I will be hacking it but if you need a physics library believe me start here.

On the AI and object management side of things I am also lucky, I have some Ansi C libraries I wrote and that I will be porting over.  These libraries are nice and generic and handle a wide range of what this game will be needing; I built them over the past few years so they are nice and stable, computationally efficient, small and robust.

[Note: When looking at AI engines almost every one needs some tweaking based on platform limitations, the game you are building and the specific outcomes you want.]

Next up I'll be dealing with all manner of design topics, level creation and idea brainstorming; then it's on to my first iPhone tests.  One very important thing, more than anything else I will be writing code, design is important but it is no substitute for coding and testing.  Small teams need to concentrate on building their product and not thinking about building it.  I think my approach is very similar to the 37signals Getting Real approach except rather than web-based development I am doing mobile development. Of course all that said the best development methodology is the one that works for you.

Eventually as I build I will be looking for beta testers. I am not sure how I will handle the beta program yet but I do know I'd like testers to get the game for free when it is released.  I won't setup a list just yet but follow along as when I get close I will put the request out here. 

Onward we go.

Guess I wasn't looking well enough, because today I (finally) stumbled upon a solution which meets all of my needs and more, Assembla.

If you're looking for a place to host your development projects, I'd highly suggest Assembla, even if only for the *free* hosted Subversion repository which can be made private or public, unlike other free services which only offer public open-source hosting. Not that I'm knocking Sourceforge or Google Code, it's just that I'm working on a consulting project that can't be left out in the open (as I'm sure is the case with many of you out there as well).

Here's a list of their plans (current as of this posting):

...and since you probably can't read that without clicking on the expanded image, here's the link to their pricing plans: http://www.assembla.com/tour

The array of development tools they have to offer is quite impressive, and I'm seriously considering upgrading to the Commercial plan ($12.50/month) to get more space.

For what it's worth, Box.net, if you're listening - you should really consider offering (real) WebDAV support and/or Subversion through your API, because *that* would make your site the killer app I've been waiting/paying for.

Also, here's another great post with information about Assembla:
http://coding-time.blogspot.com/2008/04/free-subversion-wiki-at-assemblacom.html

...and they also have a great post about Subversion and how it works:
http://coding-time.blogspot.com/2008/04/subversion-visually-explained-in-30sec.html

Again, it's very simple and you'll have it running in less than a second. Inside your repository, do:

hg serve

By default, you won't see any output. You can verify things are working by navigating to http://localhost:8000/.

Now that you're sharing your repository, Charlie can point his browser to http://[your machine name]:8000/ and browse your changelogs, files, tags. If he wants to start making changes, then he would:

hg clone http://[your machine name]:8000/ destination_directory

This will print out some status messages about what it's doing. Now Charlie has a repository one his machine that he can start working with. If I make subsequent changes, Charlie can pull them into his repository by doing:

hg pull http://[your machine name]:8000/

And vice versa, if Charlie commited some changes, he would run "hg serve" and I would pull from his computer.

This is merely an introduction to doing some lightweight collaboration. In this scheme, since the "hg serve" provides read-only access, we are using a "pull only" model. This may not be practical depending on your project, but again, this is a quick and easy way of sharing and collaborating on code.

Having built Python and Mercurial on the server and created a Mercurial user with the SSH keys of the individual developers I thought it would be easy sailing this morning. Not a bit of it and all of the problems stemmed from the lack of by default support for SSH in Windows.

Like most people I use the Putty Tool Suite for my SSH needs on windows. However simply aliasing putty to ssh doesn't work. There are some key command switches that are different (including the trivial but annoying -P instead of -p for port).

Coming from a Java Subversion background I am used to having a portable library to take care of my ssh protocol needs. I also use OSX for my home development and that obviously provides a UNIX ssh command-line implementation, hence hassle-free SSH based source control.

The command line tool turned out to be the root of all my problems, both Eclipse and NetBeans Mercurial plugins don't provide an implementation of the Mercurial client, instead they delegate it to the Mercurial client on the host OS, that in turns delegates ssh protocol invocations to the command line SSH.

The solution is simple once you know it, in the Mercurial.ini file you can alias ssh to Putty's plink executable. There is in fact an example in the Mercurial book. Better still you don't have to specify the key used if you are using Pageant.

However getting the first station to work was incredibly hard work. I even downloaded Cygwin just to get a more normal Unix ssh but by that point I had put a typo into the ssh alias and was getting a very weird error whenever I invoked Mercurial and I'd lost the forest in the trees.

At one stage I even gave Bazaar a go, hoping that SFTP might cure all my ills. However Bazaar uses Paramiko for it's SSH support and on Windows that was failing due to its inability to find an OS source of entropy.

Server-side Python also let me down a bit as I was having an issue with the zlib module and after similar experiences with Ruby I knew that this would be because I must have compiled Python before zlib. Despite cleaning and re-configuring Python it still didn't build the zlib module and in then end I had to go and run configure within the zlib module manually prior to a full Python build. This is exactly the same issue I have had with Ruby, what is the problem with this library?

Once you've done it once Mercurial repositories are actually easier to setup and manage than SVN (and that itself is pretty easy once you've done it a few times) and if you are working in a UNIX environment then they are extremely compelling.

However on Windows you are currently going to either do a lot of preparatory reading or be ready to set aside six hours to prevent frustration. In my case it probably didn't help that I am also the one selling the utility of Mercurial. The pioneers always have the arrows in their backs; on the other hand they also get to better places long before anyone else.

If the bug/change you're trying to make is anything beyond the most trivial task, it would be great to have your sources under version control so you have the freedom to try things and backtrack—you know, one of the basic ideas behind version control. So, now you're stuck. There's too much overhead to create a whole new branch just for this one fix. Do you resort to renaming files and folders and moving back and forth on your editor's undo buffer? C'mon now, behave.

When the tools aren't working for you, find a new tool! Enter Mercurial. I won't get into the interminable debate between Mercurial and Git and other DVCS's. Suffice it to say that they are all the NBT, and distributed VCS are a superset of centralized ones. I've chosen Mercurial for pragmatic reasons: 1) works well on Windows and 2) is implemented primarily in Python.

The basic idea is, you can use Mercurial on top of your current, centralized version control system. This way, you get all of your local sources under version control independent of what the rest of your company uses. It's a simple idea, but it frees you from worrying about how to manage changes you're making in your local area. Another situation I frequently find this useful in is when I'm writing a one-off script that I'm not sure if I want to commit to the repository. But, the script is complex enough that I'll need to iterate a few times. Wouldn't it be great to have it under version control? Here's how:

Install Mercurial

I'm on Windows, so I just go for the Windows binary package where Python and everything is all wrapped up for you. You can also install it with cygwin, if that's your bag. Make sure C:\Mercurial (or wherever you installed it) is in your path.

Now, you're good to go. The executable name is "hg" (get it?) and if you type that without any arguments at command prompt, you will see a list of basic commands. All the concepts of version control that you're familiar with are all there. Let's walk through an example of putting your sources under version control and making some changes.

Create a new repository

The first thing you'll do is create a new repository from your current sources. Let's say you're working on on a project in C:\projects\GoogleKiller. Navigate to that directory, and type:

> hg init

That command should return silently. It generated a .hg folder in that directory where the metadata is stored. You've just created a repository. You can now do:

> hg status
? GoogleKiller.py
? GoogleKillerTests.py
? README.TXT

This tells you that mercurial sees three files, but none of them are tracked. To start tracking them, simply:

> hg add
adding GoogleKiller.py
adding GoogleKillerTests.py
adding README.TXT

Without specifying any files to "hg add", you've added all the files in the directory. Now, the last step to getting these sources in the repository is:

hg commit -m "Initial checkin!"

The -m argument is the log message for the checkin. You can track the history of commits with the log command:

> hg log
changeset:   0:8c047c4da9a4
tag:         tip
user:        bentsai@example.com
date:        Fri May 30 17:32:17 2008 -0400
summary:     Initial checkin!

Now you're ready to roll with local version control:)

Start coding

The commandline help for mercurial is pretty good. The basic commands you'll care about are:

• hg status (to see what files have been modified)
• hg diff (which prints out a unified diff of what's changed)
• hg revert (for backing out of changes)

To get more details on these commands, just type "hg help <command>". There are other tweaks you can make to the usage (the documentation is good), but that's the general idea. Now you're free to get on with coding!

The process for getting up and running is pretty low on friction, which is why I like it. This doesn't even begin to touch the real boon of DVCS's—actually collaborating with others. But this technique takes advantage of Mercurial's speed, easy-of-use, and unobtrusiveness for a rapid solution to a fairly common problem.

Update (June 1, 2008): I should note that using Mercurial for version control isn't limited to code. Any situation you're keen on rolling back changes, this could work. Before I found out about Mercurial, I thought about using Subversion for such a purpose. But the pain was setting up a server - with Mercurial, there is no centralized server to setup. The only thing Mercurial does is add an ".hg" folder in the root. Once you have it installed on your computer, you've got localized Time Machine-like powers at your fingertips.

Update (June 2, 2008): Here's someone who's using Mercurial specifically with Perforce and described his workflow more extensively than I have.

La pagina dei download, oltre a rendere disponibile il setup completo, offre anche vari bundle, ognuno dedicato ad un linguaggio di programmazione / tecnologia specifico (il design modulare è un’altra delle novità introdotte in NetBeans 6.0).

[via: html.it || ossblog.it]

Mis maestros se quejaban de esos trabajos parchados. ¿Cuál era su objetivo? Siendo idealista querían que convivieramos, nos ayudaramos, formaramos sinergía. Siendo pesimista, aunque está de moda llamarle a eso "realista", querían simplemente un trabajo que pudieran leer sin tener brincos inesperados. Como si en una casa te golpearas la cabeza porque una puerta está más baja que las demás.

Pero píensalo bien. Ambos puntos de vista son interesantes. Si hacemos software, ¿cuál es la probabilidad que tú y tus amigos hagan algo más grande que por separado? Y al mismo tiempo, a los clientes les fascina la experiencia continua. Hoy te hablo de herramientas para trabajar con las diferencias.

Hasta hace poco me di cuenta que podríamos separar a los ingenieros por su capacidad de hacer un buen merge. Pero para esto tenemos que dotarlos de buenas herramientas o será más un concurse de resistencia al aburrimiento. Mi favorito es kdiff3. Es una herramienta simple, visual y poderosa para batallar hasta con 3 versiones concurrentes de un mismo código. Se combina muy fácil con mercurial, pero ese es un tema distinto.

Por otro lado siendo cultista de Vim no puedo sino mencionar que vimdiff está ahí a unas teclas de distancia. Es tema de otro post las bondades de Vim, pero mi consciencia no me dejaría tranquilo si no explico por qué pongo a kdiff3 sobre vimdiff. Vim es el programa a aprender a usar para considerarse ingeniero, pero eso lleva una vida. Y estaría mal que impusiera un mundo sin buenos merges. Kdiff3 lo puedes aprender a usar en 5 minutos. Es como decirte que comas mejor, que eso te dará una calidad de vida a la larga. Por mientras no tomes refrescos negros.

He creado tres directorios para realizar las pruebas.

git_github: versionará empleando Git y es alojado en el servidor libre de GitHub.com
git_assembla: versionará empleando Git y es alojado en el servidor libre de Assembla.com
hg_freehg: versionará empleando Mecurial (HG por el símbolo del elemento químico Mercurio) y es alojado en el servidor libre FreeHG.org

Para el caso de Git se puede emplear la seguridad de un certificado RSA el cual podemos crear desde el directorio home de nuestro usuario:

cd .ssh
ssh-keygen -t rsa
<nombre para el certificado>
<password>

Para mostrar la llave pública realizamos la impresión en pantalla de un archivo generado en el proceso anterior:

cat id_rsa.pub

Esta llave se puede ingresar tanto en el Sitio de Assembla que hayamos creado como en el Perfil de GitHub.
Assembla es un poco más complejo debido a las mayores opciones que permite. Por ejemplo el soporte para Git debemos agregarlo ya que no está activo por defecto y podemos elminar Subversion.

qct
qgit

Para el caso de GitHub realicé lo siguiente:

cd twitterrssmultifeed/
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@github.com:adagio/twitterrssmultifeed.git
git push origin master

Ese archivo README está vació pero ya se encuentra en el repositorio. Luego de copiar las fuentes de mi aplicación las agregué, hice commit y nuevamente push. Para el caso de Assembla no realicé el paso de crear un archivo README que no forma parte de mi aplicación sino de un ejemplo. Así que luego de copiar las fuentes en el directorio ejecuté los siguientes comandos.

git add .
git-commit -m "first commit"
git remote add origin git@git.assembla.com:twitterrssmultifeed.git
git push origin master:refs/heads/master

Debido al certificado RSA el password me es solicitado, esto se puede automatizar.

Para el caso de Mercurial realizar un proceso similar fue algo accidentado ya que no completaba la operación de commit. Lo más sencillo fue clonar el repositorio al directorio local:

cd mercurial_freehg/
clone http://freehg.org/u/adagio/twitterrssmultifeed/ twitterrssmultifeed/

Y Luego de copiar las fuentes emplear una aplicación que realice el commit ( hg status, hg add, hg commit ):

qct

Esta aplicación detecta de forma automática el sistema de control de versiones empleado. Seguramente lo hace buscando los ficheros .git o .hg, de forma similar para otros sistemas como subversion o cvs.

Finalmente el proceso de push lo realicé sin problemas.

hg push http://freehg.org/u/adagio/twitterrssmultifeed/

Vemos que Git y Hg el proceso de commit está separado del push. La teoría de estos sistemas debe justificar esta implementación y el uso de herramientas gráficas totalmente integradas al sistema operativo como Tortoise nos ocultan estos interesantes detalles que podrían ser muy útiles cuando deseamos conocer si ya hemos sobreescrito algún archivo entre otras aplicaciones bastante prácticas.

Pensaba probar el promocionado sistema Bazaar pero parece que los dos que he explicado son mejores. Es una interesante tarea para quien los use conocer sobre la comparación de fuentes, creación de forks, exportación de proyectos, candados, etc. Pero personalmente le doy el uso más sencillo de versionado personal.

Alrededor de estas tecnologías sitios como Assembla están brindando la posibilidad de realizar un seguimiento a reporte de bug, tener salas de chat, establecer hitos, seguir un proceso formal de desarrollo, entre otras herramientas que deben ser seleccionadas de acuerdo a la naturaleza del proyecto que se tenga.

Saludos.

gem sources -a http://gems.github.com/

Hace mucho, mucho tiempo, existía una catedral que tenía un mercado a lado, blah blah... Hoy el open source es igual y al mismo tiempo distinto que lo ESR nos dijo. Hoy el open source no es el bastión idealista que la GNU quisiera. Hoy el GNU/Open Source es pragmático y las empresas juegan el juego. Básicamente es lo mismo que con internet.

Siendo yo idealista, aunque los amigos piensen lo contrario, me siento orgulloso de hoy presentarles un nuevo mercado. ¿Qué significa esto? Significa que hoy las gemas (de ruby) tienen un sitio fácil para exponer sus forks. Entiendo si esto te causa conflictos. Entiendo que sientas que los forks diluyen/debilitan al open source. Y finalmente muchas veces es por causas muy bobas. Pero creeme, el mundo es mejor por ello.

Frecuentemente ponen como debilidad que haya tantas opciones. Ciertamente marea descubrir si git es mejor a mercurial o si debes aprender prototype o scriptaculous. Como yo lo veo, no lo hagas. Elige uno, crece en él. O ve ambos, entiende pros y contras. O alterna un poco de este, un poco del otro. Lo importante es entender que cada persona aprende y piensa distinto. Es fútil creer que "siendo objetivos" encontraremos un claro ganador. Let it be.

Teoria culturală se referă în mod expres la cultura populară şi la arhetipurile culturale. Cultura populară acceptă şi o definiţie negativă, revelatoare pentru noi. Despre cultura populară de acum nu s-ar putea spune că-i purtătoarea sau depozitara unui mesaj de autenticitate arhaică. Cultura populară nu are vreo legătură cu folclorul, chiar este total opusă folclorului. Cultura populară  ideală, mesianică, pentru „salvarea Pământului”, ar putea fi numită : “Cultura asimilării etichetelor ecologice”. Cultura populară ar putea deveni parte esenţială a discursului public.

Dezvoltarea durabilă este centrată  pe economia de piaţă a produselor de calitate. Atât în sensul calităţii ontice, cât şi al calităţii statistice. Calitatea ontică a produsului înseamnă racordarea produsului la înclinaţia ontică a individului, constatată de el prin faptul că achiziţionarea produsului duce la creşterea forţelor personale, a capacităţilor individuale. Aceasta constituie esenţa conceptului “democraţie achiziţională”. Iar calitatea statistică  a produsului este controlată  de instrumentul managerial Sixsigma aplicat în industrii, --patentul aparţine firmei Motorola--, dar în cultura română ea este controlată cu ‚metodologia Ioan Plăcinţeanu’ pentru prelucrarea datelor numerice dintr-un laborator şi dintr-o industrie. Odată cu intrarea în Uniunea Europeană, produsele de ‚calitate ontică’ totală trebuie sa fie însoţite, când sunt oferite pe piaţă, de ‚etichete ecologice’ care certifică valoarea lor pentru durabilitatea noastră holistică. Nu este suficient să oferi pe piaţă produse de ‚calitate ontică’  dacă ‚etichetele ecologice’ nu sunt sprijinite de Teoria culturală.

Să ne lămurim ce-nseamnă cuvântul cultura, înainte de a defini, -- nu riguros, ci ostensiv--, Teoria culturală. Termenul cultura se referă la diverse activităţi umane , fie, --printr-o unificare holistică a diversităţii--, la ‚activitatea umană’ în general, incluzând toate acţiunile antropice de control şi dominare a naturii. Cuvântul cultura provine din latinescul colere, ceea ce se traduce fie a locui, fie a cultiva, fie a onora. Definiţiile diferite ale culturii reflectă  teorii felurite ale cunoaşterii, ale înţelegerii, şi criterii diverse în evaluarea activităţilor antropice. Scriind o carte cu titlul ‘Culture: A Critical Review of Concepts and Definitions’, în 1952 Alfred Kroeber  şi Clyde Kluckhohn compilau un inventar cu peste 200 intrări ale cuvântului cultură. In secolul XVIII şi începutul de veac XIX, cărturarii Occidentului postulau congruenţa între Cultură  şi Civilizaţie, amândouă  fiind opuse Naturii. Întrebuinţarea populară a termenului  cultura  reflectă  accentuat stratificarea socială. Cuvântul cultura  este utilizat ca referire la activităţile unei elite bogate, (deja în perspectiva din Împărat şi proletar, Mihai Eminescu  sublinia consumerismul exclusivist al acestor elite), fine cuisine, haute couture, arhitectura şi decorarea  locuinţelor, achiziţionarea operelor de artă. Către sfârşitul de veac XIX, în Belle Époque şi dominarea pozitivismului, antropologii propuneau  o definiţie a culturii pe care Occidentul putea s-o aplice la o paletă mai largă de societăţi. Se exprima clar ideea relaţiei, chiar identificarea culturii, cu firea omenească în general şi  natura intrinsecă a omului. Rădăcinile culturii par a se ascunde în universala capacitate umană de a clasifica experienţele, de a le codifica şi comunica simbolic. Grupuri de oameni aflate la mari distanţe dezvoltă  culturi distincte şi caracterizate prin unicitate, însă elemente ale diverselor culturi se pot propaga “prin civilizaţie” de la un grup de oameni la altul. În general, se ştie, există cultură materială şi cultură simbolică, nu doar prin reflectarea unor tipuri diferite de activităţi umane, ci şi pentru că ele furnizează tipuri distincte de date, cu metodologii de tratare diferite. Ca ecologist industrial, consider că arheologii îşi focalizează cercetarea pe cultura materială, iar antropologii culturali ai aceleeaşi epoci sunt interesaţi mai ales de cultura simbolică. Dar în finalul integrator ambele grupuri de cercetători se arată preocupate  de relaţiile între cele două dimensiuni ale culturii.

Această ştiinţă integratoare se cheamă “Teoria culturală”. Este o ştiinţă generativă născută din Trivium, nu din Quadrivium. Care-i locul ei în cultura română ? Când Titu Maiorescu vorbea românilor despre “Forma fără fond”, construia de fapt discursul despre fondul “Teoriei culturale”. Ce a însemnat Junimismul, altceva decât un sistem de producţie animat de “nouă meşteri mari, calfe şi zidari” ai cuvântului care încercau să construiască  în România  peretele dinspre Răsăritul european al modernităţii, după schiţe şi planuri ce veneau din Apus,   prin expansiunea iluminismului scoţian? Societatea Junimea se afirma ca far de valori culturale urmând programul cărturarului scoţian Thomas Carlyle (1795–1881), cunoscut şi admirat în Germania unde  studiaseră junimiştii ce proveneau din familii înstărite. Junimismul era programul tranziţiei de la Iluminismul clasic al secolului XVIII, cu idealuri prevestind liberalismul şi  incorporate deja  în paşoptismul românesc, la spiritualitatea dinamică a secolului XIX,  ilustrată mai ales prin cultura germană, insista Carlyle.

Cel puţin pentru că fundamentează  acum acordarea  etichetelor ecologice  pentru produsele comerciale, “Teoria culturală”  devine ‚cale regală’ pentru înţelegerea lumii postmoderne, a  felului cum evoluează, şi mai ales, a felului cum va  supravieţui. Dintre toate ştiinţele de până acum, tocmai “Teoria culturală” este esenţială pentru supravieţuirea omenirii.

“Teoria culturală” doar întârzie venirea Zilei de Apoi, căci Apocalipsul nu poate fi evitat. Bibliografia pentru “Teoria culturală” e vastă. Titluri relevante pot fi întâlnite în locuri neaşteptate. În primul episod al trilogiei cinematografice “Matrix” a fraţilor Wachowski, eroul Neo ascundea programele de computer,  pe care le vindea la negru, între coperţile unei cărţi semnate de Jean Baudrillard. Autorul a fost un filosof real, cu texte formidabil de revelatoare pentru “Teoria culturală”. Jean Baudrillard fusese  influenţat de ‚Oracolul erei electronice’, Marshall McLuhan, despre care s-a argumentat serios că a fost ‚primul postmodernist’. Universitarul canadian Marshall  McLuhan devenea cunoscut în România la  insistenţa protocronistului Mircea Maliţa, şi prin titlul unei cărţi tradusă în anul 1975 : “Galaxia Gutenberg”. Unde profesorul McLuhan argumenta ideea că inventarea tiparului a fost heraldul revoluţiei industriale. O consecinţă a „revoluţiei tiparului” ar fi fost neaşteptată fragmentare a societăţii umane din Europa,  după unificarea religioasă prin creştinism, ducând la înflorirea individualismului. McLuhan susţinea că, spre deosebire de ascultarea colectivă a mesei liturgice, citirea în gând a Bibliei, --sau oricărei cărţi--, era un act individualist de percepere a lumii. Cu  inventarea tiparului se nasc stelele pieritoare ale Galaxiei Gutenberg, cărţile multiplicate în serie pe hârtie, fiecare Carte fiind semnată  de un „honnête homme”.

Mediile de comunicare electronice erau prezentate de Marshall McLuhan drept o revenire la “gura satului”. Adică la modul ontologic colectiv de percepere şi prezentare a lumii. Ubicuitatea manifestă a  mediilor de comunicare electronice duce însă la emergenţa „satului global”, formula-i celebră. Opera filosofică a lui Marshall McLuhan este relevantă mai ales prin tentativa de normare a eticii mijloacelor de comunicaţie electronice. Acolo, se pare, Marshall McLuhan a fost influenţat de filosoful iezuit Pierre Teilhard de Chardin. Acela care gândea că utilizarea electronicii de către om preia, extinde, şi amplifică impulsurile electrice neuronale din creier.

În istoria Teoriei culturale, de la McLuhan a rămas faimosul dicton : “Mediul este mesajul”. Expresie extremă. Ea identifică “forma” cu ”fondul”, şi aminteşte, --dar antinomic--, formula “Forma fără fond”. Marshall McLuhan se referea atunci la explozia informaţională adusă de televiziune, cu audienţa sa largă, pe care Jean Baudrillard o va denumi Agora-display, expandată apoi în realitatea virtuală a filmelor fraţilor Wachowski. Reamintim că  “Matrix” este o producţie a celei de a şaptea arte cu acţiunea plasată într-o lume super-high-tech, unde IT, --“Information Technology” ori “tehnologia informaţiei”--,  va fi crescut la stadiul generării lui Homo Cyber Sapiens. Fraţii Wachowski sesizau faptul că între dezvoltarea tehnologică şi Teoria culturală există o legăturã.  “Teoria culturală” de azi  este  deosebit de importantă chiar şi pentru Banca Mondială care finanţează proiectele dezvoltării durabile şi măsoară impactul ambiental al încălzirii globale, măsuri după care sunt acordate şi etichetele ecologice. Deci Teoria culturală este acel domeniu al studiilor culturale în care-i analizată cultura consumului de bunuri (incluzând aici şi serviciile) produse industrial, "de masă", şi comercializate pe piaţa liberă.

Imperialismul cultural este definit acum prin cultura populară cea mai comună : cultura consumerismului. Dar antropologii care văd cultura ca o reţea complexă de organigrame mobile, conectând oameni reali din diverse locuri şi formaţiuni sociale, resping identificarea între cultură şi consumul de bunuri. Practic numai prin această identificare, cultura populară instituie o “logică a consumerismului”. În această înţelegere a termenului, postmodernismul se (re)defineşte tocmai prin "cultura populară". Chiar titlul cărţii lui Fredric Jameson din anul 1991 : "Postmodernismul, o logică a culturii capitalismului târziu", este relevant. Deja profesorul  Marshall McLuhan, filosof în termeni informali dar ocupând funcţia de director la Center for Culture and Technology  al Universităţii din Toronto, era solicitat de oameni de afaceri nord-americani să ţină prelegeri  foarte bine plătite privind felul în care un nou tip de cultură ar putea influenţa şi augmenta consumul, considerat în doctrina economică a Statelor  Unite ale Americii a fi  Motorul Dezvoltării.

Cultura populară devine  multiplicarea etichetelor consumeriste mai mult ori mai puţin identice, o “copy culture” - cultură a copiei. Începuturile postmodernismului ar fi fost astfel marcate, pe scara de timp a istoriei, prin transfigurarea subiectului naturii moarte din tablourile  clasice, în reprezentări de mărfuri identice stivuite pe rafturile magazinelor. Evident, cele mai cunoscute producţii culturale care glorifică produsele de consum sunt imaginile multiplicate ale sticlelor de Coca Cola şi ale cutiilor de supă Campbell din arta-pop a lui Andy Warhol. Conţinutul acelor opera de artă acoperea ca o viitură creaţiile expresionismului  abstract, căci după Fredric Jameson, finalul apoteotic al modernismului avea drept decor tablourile de acţiune ale unor artişti plastici precum Jackson Pollock ori Willem de Kooning.

Deşi joncţiunea aceea cu nenumărate pericole anunţate,  vorbesc despre  anul 2000, a fost depăşită benign, să adăugăm că Fredric Jameson corela emergenţa postmodernismului cu tipul particular de milenarism aflat la îmbinarea dintre mileniul al doilea şi mileniul al treilea.

S-a ajuns să se vorbească despre "sfârşituri", printre care, să rîdem acum!, despre sfârşitul Istoriei. Altminteri este intelectualiceşte riscant să vorbeşti despre postmodernism, a cărui premisă definitorie este tocmai respingerea metanarativului. Tind să cred că interdicţia impusă metanarativului înseamnă de facto restatuarea pozitivismului care introducea un cloazon între Observator şi Obiect, un cloazon care blochează din actul de observaţie fluxul ne-standardizat  al experienţei ontice.

Faptul că nu există anecdotă ce uneşte intrarea intuitivă cu experienţa pentru a fabrica noul adevăr universal –în postmodernism este interzis op-ul  „De inventione veritatis”-- creează dificultatea înţelegerii postmodernismului într-o unitate. Ce anume înseamnă integral şi de facto postmodernismul, altfel decât în fragmente de subiect conectate discursiv prin conjuncţie Booleană ?

Dincolo de chestiuni ţinând de tranziţii arhetipale în cultură şi religiozitate, logica teoriilor postmodernului poartă în ea şi conotaţiile unor generalizări sociologice. Lumea postmodernă este asociată cu inaugurarea unui "nou tip de societate", botezată cu o mulţime de nume alternative : postindustrială, consumeristă, informaţională, electronică, de înaltă tehnologie, societate media etc. Dar în primul rând o societate caracterizatã prin emergenţa fenomenului „cool”.

Deja primul teoretician postmodernist, Marshall McLuhan, introducea dihotomia de clasificare a mijloacelor de comunicare, în categoriile „hot” şi „cool”. Marshall McLuhan caracteriza un mediu informaţional ca fiind „cool”  dacă el necesită un mare număr de participanţi pentru a crea vreun sens acolo. Marshall McLuhan se referea într-un mod specific la televiziune. Chiar şi acum, telenovelele capătă sens doar pentru că sunt privite de foarte multe persoane. Ceea ce McLuhan nu a trăit să mai vadă, era unificarea globală între text,  având potenţialul conceptului, şi mijloacele de comunicare electronice,  uniune făcută  posibilă  de Internet.

Împrumutând de la McLuhan, fiindu-i, într-un fel, continuator intelectual, Jean Baudrillard -- „the French McLuhan” statua discursivitatea  electronică drept „cool”. În practicile discursului electronic, sublinia Baudrillard, comunicarea înlocuieşte schimbul de simboluri cu comutabilitatea, exterminând realul semnificaţiei. Luciditatea lui Jean Baudrillard este echivalentã unei „Terori exercitate de Spirit”, cum îl acuza ideologul Alain Minc ? Împingând acuzaţia lui Alain Minc până la punctul de evanescenţă, am conchide că Buda, Confucius, Zoroastru, Iisus Christos şi Mahomed au fost cei mai mari „terorişti spirituali” din Istorie.

Într-o lume unde Zeul Omiscient a fost înlocuit de Semiologie, ne putem întreba : Este „cool” un limbaj ? În cartea  „Culture Jam: The Uncooling of America”, Kalle Lasn supralicita importanţa factorului ‚cool’, ce transformă cultura nord-americană într-un capitalism în care consumerismul nu-i doar stil de viaţă, ci şi un limbaj. ‚Cool’ ar fi un ‚etos al corporaţiilor’, extrem de manipulativ şi motivând cultura americană doar pentru a impulsiona creşterea economică. Privind  conceptul "cool" în contextul consumerismului şi al exploziei globalizante a economiei de piaţă, atunci "cool" este acel detaliu din 'calitatea ontică' a unui produs care intensifică individualitatea, în singularitea sa radicală, pentru persoana care achiziţionează produsul respectiv.

În numărul din noiembrie 2001 al revistei „Wired magazine”, apărea articolul „Fenomenul Cool” , insistând pe conceptul ‚cool’ ca ‘forţă revoluţionară’ atât în istoria culturală, cât şi în istoria producţiei tehnologice : „Cool could be beamed into 100 million homes, tracked and data-processed. Downloaded from across an ocean. Or bounced off a satellite on your wrist.”

„Cool” rezultă dintr-o suprapunere între Cornul abundenţei şi conul invidiei. ‚Cool’ este un obiect al societăţii de consum, de exemplu un gadget etc la care nu ai acces. Însă invidia este înlocuită în secolul XXI cu o depreciere egalizatoare : „Dacă  vecinii tăi au un produs cool, atunci în mod hotărât produsul nu mai este cool.”

Deci încercarea de a prinde fenomenul ‚cool’ în cultura populară este mai curând o capcană consumeristă. Cum remarca şi Lewis MacAdams, autorul cărţii „Birth of the Cool” : „Oricine încearcă să definească termenul ‚cool’ constată repede natura lui mercurială, de argint viu ce nu poate fi prins. În momentul în care un subiect este definit drept ‚cool’, natura sa ,cool’ se evaporă.”

Printr-o identificare şi o multiplicare industrială a produsului, dispare curând acel caracter de singularitate radicală care intensifică individualitea. Fenomenul ,cool’ este deci caracterizat printr-un orizont de timp foarte scurt.

Adaptarea la cerinţele ‚cool’, şi integrarea culturii populare, înseamnă în acelaşi timp o aculturaţie ce introduce o fractură majoră între tradiţie şi post-modernitate. Să mai observăm că în România comunistă, unde ‚cool’ era prohibit, însă ţara era supusă unui program de asimilare a ‚revoluţiei tehnico-stiinţifice contemporane’, protocronismul lui Edgar Papu a încercat să construiască atunci o punte între tradiţie şi o post-modernitate fără ‚cool’. 

Titus Filipas 

Image from Wikipedia

The plugins I've current stablized on is:

• Maven2 plugin: http://m2eclipse.codehaus.org/ (update-site: http://m2eclipse.sonatype.org/update/)
• PMD for static analysis of java code: http://pmd.sourceforge.net/integrations.html#eclipse (update-site: http://pmd.sf.net/eclipse )
• Findbugs for static analysis of java bytecode http://findbugs.sourceforge.net/manual/eclipse.html (update-site: http://findbugs.cs.umd.edu/eclipse/)
• Checkstyle for doing code the Right Way(tm). http://eclipse-cs.sourceforge.net/ (update-site: http://eclipse-cs.sourceforge.net/update)
• EclEmma http://www.eclemma.org/ for junit codecoverage (update-site: http://update.eclemma.org/) Very nice to get a view of how much your tests cover your code. 50% should be possible right? :)
• SpringIDE for code completion in spring bean xml-files. Very very nice! http://springide.org/project/wiki/SpringideInstall, (Update-site: http://springide.org/updatesite)

I use the code formatter extensively as possible. It's very nice to get these things like a gift instead of spending time on wrapping lines and formatting by hand.

When using the codeformatter you really can benefit from "Save Actions". The most timesaving feature for me so far. My setup currently includes all checkboxes, and a stack of additional action. No more time spent inserting spaces between ) and {

Good stuff!

For my sparetime project I'm currently exploring other plugins:

• Mercurial eclipse plugin: http://www.vectrace.com/mercurialeclipse (Update-site: http://www.vectrace.com/eclipse-update/)
• new Scala plugin : http://scala.sygneca.com/tools/eclipse

The mercurial plugin isn't quite ready yet, but it's getting there. Things are happening, and as the mail and website for the new scala plugin suggests that plugin isn't quite there yet.

I dont mind, it gives you that pioneering feeling :)

If anybody should pop by and see this list, feel free to suggest all those nifty plugins I'm missing!

Happy coding

Another option for version control we can use.