Github down, so what?

Did you see all these tweets complaining about Github problems these days? And all these (low level) articles on tech blogs/websites? Here are some examples which made my laugh:

Github a été victime de pannes à répétition, privant les très nombreux utilisateurs d’accès à leurs sources

Source: http://www.lemagit.fr/article/developpement-open-source/11789/1/github-victime-pannes-repetition/

Which means that « developers did not have access to their sources ». Really? Developers already have their sources locally if they are working on them!

Github going down is no small thing, developers which acts as a central repository for much of the open-source code that runs our world.

Source: http://iwgcr.org/github-down-twice-in-two-day/

Agree, it is not a « small thing » but are we speaking about a git-based system i.e. the so funky decentralized distributed version control system?! If github is down you can, at least, still continue committing things locally (Do you remember when you were using SVN?). Right?

If you still need to push your sources and share them with your dev team: git is decentralized i.e. you can change the remote repository to a temporary google code, bitbucket, wtfgitrepohostingsystem.com repository and come back later on github. RTFM: ‘git help remote’

Do you still need more to work? Come on developers!

Related articles

• Uh oh: Github’s down! (gigaom.com)

Pushing your Web services in the Cloud in 5 minutes…

… or less! Heroku is defined as a « Cloud application platform ». I just want to redefine it to « Awesome Cloud application Platform ». So, this awesome platform provides a way to host and scale your application in the Cloud really easily with 3 or 4 commands…

Since I am currently working on my talk at #OW2Con 2011 (coming later this week) dealing with BPM, Services and the Cloud, I wanted to host some Web services on several places. I never had time to test Heroku but I just took this precious time today. After looking some examples, I created a Maven project template (no I do not have time to create an archetype, maybe there is one somewhere) which uses Jetty and Apache CXF to expose JAXWS annotated classes as Web services. So now, using heroku to freely expose your services is easy as:

1.  Sign up to heroku
2. Download the heroku client for your platform
3. Clone/Fork the repository at https://github.com/chamerling/heroku-cxf-jaxws
4. Add your own services
5. Login to heroku ‘heroku auth:login‘
6. Create the app on heroku ‘heroku create -s cedar‘
7. Push your services to heroku ‘git push heroku master‘. There is a git hook somewhere which just automatically compile and start your application after you pushed it.
8. Open your CXF services summary page ‘heroku open’

The default application name is some random one, you can rename it by using the ‘heroku rename yournewname‘ but in the current case I had an issue on the generated Web service endpoint name. So I suggest restarting your app after renaming (have a look to the ‘heroku ps‘ command).

That’s all, that’s quick!

Invoke business services from service bus kernel

Let’s introduce what it means…

While Petals ESB does not provide any solution to invoke services directly from the kernel/component Java code, the DSB now provides a solution for that… By using this DSB feature, we can really use the power of service oriented architecture directly in our code. No more direct calls to services, you just need to call the client and say which service you want to invoke. The service bus will resolve the endpoint and route the message to the right place by using the right way/path. By using this way, you do not have to care if you need to speak with a SOAP service, a JMS queue or a REST service: Just call the service, the DSB will do the rest.

Now some code…

So, let’s have a look on the client code and first, let’s imagine that you have a web service which is bound to the service bus. Once bound, a DSB endpoint is available inside the DSB, and all messages which are sent to this endpoint will be forwarded to the final web service. One basic approach is to create a web service hosted by the service bus which ‘consumes’ the DSB service. As a result, a SOAP message sent to the DSB web service will be forwarded to the DSB endpoint which will forward it again to the final web service. Allright, but this is just for external SOAP clients and it is impossible to invoke anything firectly from the service bus kernel.
Now, let’s call the DSB endpoint from Java code… To put ourselves in a **real** case, let say that you are DSB kernel developer and that you want to say hello to the world (oh s*** really?) by using the *HelloWorldService* which is bound to the bus. Let’s code this client:

https://gist.github.com/1186183

So, just get a *org.petalslink.dsb.service.client.Client* from the *org.petalslink.dsb.service.client.ClientFactory* factory, create your *org.petalslink.dsb.service.client.Message* and send it by using the *sendReceive* method. That’s all… Let’s try to clarify what it means with a simple schema:

Hacker inside!

It looks so simple… I just deeply hacked the petals service bus kernel to provide such a thing. Why? Because the service bus is also deeply based on the JBI specification: Creating a client means that the client need to be able to receive responses and acts itself as a service on the service bus point of view. It is also built using all the component context stuff. No component context means no way to send/receive messages (component contexts are just created when JBI components are installed).
So it is really important to release the client when you do not use it anymore: There are tons of listeners and threads in the different layers which are just used to receive messages. If you do not release the client, there will be unused resources for a long time.

Need something? Just Ask GitHub…

I am using GitHub more and more: for personal open source projects (https://github.com/chamerling), for research projects (Play for now https://github.com/organizations/play-project), for organizations (OW2 will start using it soon at least for mirroring https://github.com/organizations/ow2, and we use it for the Java USer Group we created in Montpellier https://github.com/organizations/Jug-Montpellier).

This is a really nice tool and not only one other fashion tool. There are tons of interesting features and thousands mature and interesting projects are already there.

I remember a discussion almost one year ago where someone in my company was saying that git was not ready for industry. To be honest, I was not using git at this moment and did not have time to look at it, so my opinion was… no opinion. But what I can say today is that, after some months of use and with all the work GitHub guys did and with all the projects which migrated to this platform, it is probably more than ready to be widely used by all (not only GitHub, but git too).

So to come back to the main goal of this article, I was asking on twitter some days ago, what is the best tool to use to publish GitHub gists?

https://twitter.com/#!/chamerling/status/103822930152128512

Even if I got some retweets, I did not have any answers (probably since I do not have any impact on Twitter or maybe my followers are not GitHub users…). So I asked it to GitHub and the first answer is just what I need: A command line tool written in Ruby (which is published by the GitHub CEO itself) and which is named gist. Using it is sooooo simple, just launch your terminal (I still use it everyday for many things) and the gist command will do the rest. As a result, you will get the gist link you can send to your peers. Sharing a gist just take 3 seconds…
And you what are you using to gist? or even are you using Git?

WTF Spoonlet?

Ca fait longtemps que je n’ai pas parlé de code. Qu’a cela ne tienne, dans la série « Le bon gros bug de m**** », je vous présente Spoon… Dans un élan de refactoring, je me suis mis à extraire une vrai API du kernel de Petals DSB. L’idée est simple, le faire aurait du l’être: Extraire toutes les interfaces d’un projet A pour créer un projet A-api et en dépendre dans le projet A. Trois clics de souris et deux drag&drop plus loin, testons la compilation:

[INFO] ------------------------------------------------------------------------
[INFO] Building dsb-kernel
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [spoon:recompile {execution: default}]
[INFO] org.objectweb.fractal.fraclet.annotation.processor.FractalComponentProcessor
[WARNING] FractalComponentProcessor >> No value found for property 'generatorClass' in processor org.objectweb.fractal.fraclet.annotation.processor.FractalComponentProcessor
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] fail to execute</code>

[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23 seconds
[INFO] Finished at: Mon Jun 20 23:27:21 CEST 2011
[INFO] Final Memory: 50M/123M
[INFO] ------------------------------------------------------------------------

Ahah, qu’a cela ne tienne, le même en mode debug donc…

[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: fail to execute
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: fail to execute
at net.sf.alchim.spoon.contrib.maven.AbstractSpoonMojo.execute(AbstractSpoonMojo.java:96)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.lang.NullPointerException
at spoon.support.reflect.declaration.CtAnnotationImpl.convertValue(CtAnnotationImpl.java:160)
at spoon.support.reflect.declaration.CtAnnotationImpl.getElementValue(CtAnnotationImpl.java:253)
at spoon.support.reflect.declaration.CtAnnotationImpl$AnnotationInvocationHandler.invoke(CtAnnotationImpl.java:69)
at $Proxy31.name(Unknown Source)

Yeah cool, une NPE. Ah dommage, sur $Proxy31.name… Genre le proxy généré par Spoon. Et donc bon, on fait quoi la? On revert tout et on tente de bouger les interfaces une par une pour voir qui fout son bordel? Mouais… Trève de blahblah, après avoir passé quelques dizaine de minutes à bouger, compiler, reverter, voici la conclusion: Définir des constantes dans des interfaces qui sont dans des dépendances et les utiliser dans les annotations des implémentations n’est pas possible, par exemple, dans une implémentation du style :

@FractalComponent
@Provides(interfaces = { @Interface(name = "service", signature = ServiceBinderRegistry.class) })
public class ServiceBinderRegistryImpl implements ServiceBinderRegistry {

@Requires(name = BINDER_PREFIX, signature = ServiceBinder.class, cardinality = Cardinality.COLLECTION, contingency = Contingency.OPTIONAL)
private final Map<String, Object> binders = new Hashtable<String, Object>();

On ne peut pas avoir BINDER_PREFIX dans l’interface ServiceBinderRegistry qui est dans une dépendance, par contre ca marche bien quand l’interface est dans le même projet… Quand on tombe la dessus à minuit, c’est rude…