Wednesday, July 14, 2010

Google App Inventor Eclipse Plugin

Hey, in case you missed it, here it is - the App Inventor plugin for easily making Android apps straight from your favourite IDE.

Together with git, task management and debugger now you can make not only silly kitty apps, but something bigger too :-)

See it in action: (embedded Youtube video below) so wouldn't that be easy with web plugins?

Sunday, July 4, 2010

Extend Eclipse in JavaScript... or PHP :-)

The JavaScript unit tests view for Eclipse I blogged last time, wouldn't be anything special, unless you're JavaScript guy. Except the fact that it's implemented in plain HTML+JavaScript for GUI part and business logic.
Ah.. and it uses jQuery too, so I think I can label the view as an example of jQuery plugins for Eclipse :-)

This has several advantages:
- I don't need to know Java to extend Eclipse. This is great for such Eclipse IDE users as JavaScript, or PHP developers.
- many things are easier to calculate in web languages, than Java. E.g. (running JS tests, running a web poll, etc.)
- writing simple UI in HTML is dead easy. and you can use CSS :-)

The main disadvantage is difficult communication with workbench. Java APIs are complicated and hard to map 1:1 in JavaScript, however for start I'm looking at exposing only few most useful features, like selection service.

The inner workings are pretty simple. Some HTML is rendered by browser widget embedded in traditonal Java Eclipse view. Additionally, JSON and Ajax are used to keep HTML view informed what's going on in the Eclipse workbench.

I know that e4 open social is working on something similar, however how do the gadgets communicate with Workbench?

Wish me luck with final efforts on releasing Zend Studio, and you'll see more of this HTML/JS/PHP plugins :-)

Saturday, June 26, 2010

JavaScript unit tests in Eclipse

Anybody knows what's currently the most popular tool for javascript unit testing?

While figuring this out, I made up a simple javascript unit tests integration with Eclipse to easily run precious tests from my favourite environment :-)

Unit tests are simple objects with functions to test and there's a couple of JUnit-style assertions. I wonder if the above view could be integrated with some real JS unit test tool.

Friday, May 28, 2010

Understanding JavaScript libraries

I'd like to share with you some thoughts on supporting javascript libraries in an IDE. I found it quite interesting so far and I hope you'll enjoy the read :-)

Let's assume we have to add content-assist for popular javascript libraries, like jQuery or Prototype, etc, there's dozens of those.

First of all, if those libraries are written entierly in JavaScript, why do we have to add anything special? Can't some JS parser (e.g. JSDT) just take care of understanding those libraries, like it's done for Java or other languages?

Unfortunately no. Most popular convention in JavaScript world is to write libraries that self-expand themselves in runtime. For example:

/** this function adds all fields and functions to given object
jQuery.extend = function(object, fields) {
for (var field in fields) {
object.prototype[field] = fields[field];

jQuery.extend(Array, {

/** Removes an object from array
remove : function(obj) {

/** Prints JSON string of an object
toJSON : function() {

So statically analyzing above code, compiler could guess only that extend(objects, fields) function is defined and added to jQuery object. For the other functions - remove(obj) and toJSON(), we can only assume, based on some comments (and code), that they'll be added to Array object after invoking the extend() method. This extending pattern is the fundament behind jQuery plugins, Prototype and ExtJS.

Before going further into details with possible solutions, let's see what does typical static analyzer (e.g JSDT) understand. It understands basic JavaScript structures, like:

/** jQuery.function1 jsdoc
jQuery.prototype.extend = function(object, object) {}

/** jQuery function jsdoc
Array.remove = function(object) {}
Array.toJSON = function() {}

Based on above code, JSDT can provide content assist for functions and fields and properly match jsdoc to them. So maybe all that is needed is some convertion between original library source code and understandable code?

Ok so what are possible solutions to build proper JSDT data?
There's several options:

  1. improve static analysis to understand popular JavaScript patterns, such as extend patten.
  2. forget about source code and use libraries provided API documentation to derive JSDT documentation
  3. run the source code in real environment and capture it's behavior

AD1. Improve static analysis with knowledge of popular JavaScript patterns, such as extend patten.

It's possible to extend JSDT with extra logic that understands what extend() function does. Then, whenever static analyzer finds call to extend(), it can easily apply the pattern. The drawback is that there's more patterns, for example extendIf(boolean, object, fields) (in ExtJS),
or code is more complicated, for example the features to be added to object are computed in a non-trivial way. For example:

features = { // an object with various features that should be added to
various objects
objectAdditions : { object : Object, extend : function(), id :
function() },
domAdditions : { object : Element, toHTML : function() },
docuAdditions : ( object : Document, connect : function() }

for (var featureSet in features) {
Lib.extend(features[featureSet].object, features[featureSet]);

Libraries authors have a lot of invention: they either optimize their libraries for JS file size, or try to make it as human-readable as possible by adding more JS structures. In both cases we can find either more functions, similar to extend() or more JavaScript code used
to build new API.

AD2. Forget about source code and use libraries provided API documentation to derive JSDT documentation

The most successful libraries have excellent documentation. JQuery has it's own in XML, which is then converted to HTML. ExtJS and Prototype have greatly commented source code. It's worth mentioning that JS libraries source code can be found in several formats. First as a
development source code - single library is split into many separate files of logically-related stuff. Second format is the debugging source code - library in it's final single file shape, but with formatting and comments included. Finally, there's minified source code - typically a
single line, with all whitespaces and comments ripped off.

The main advantage is that everything that is officially documented/supported in the docs, will be correctly reflected in JSDT. The main drawback is that for each library a separate converter is needed. Additionally, XML and HTML structure are subject to change, so there's a risk that each new version of library will also need a new converter. Documents may also show API in ways that are not possible to encode in JavaScript stubs. For example use overloading to describe
different kinds of the same function, whereas in fact in JavaScript this is just a single function with variable number of arguments:

/** jsdoc1 */
jQuery(selector) {}
/** jsdoc2 */
jQuery(element, expr)

Finally, while parsing XML is relatively painless, the HTML is often a subject to many XML parser errors, so regular expressions may be better tool than XML parser.

AD3. Run the source code in real environment and capture it's behavior

This sounds like WIN, because after all, all javascript libraries are written to be run, so it's only matter of capturing the result.

There's two ways to capture the JavaScript structures. One way is by using Mozilla Rhino. It's a JavaScript engine written completely in Java. Rhino also has excellent debugging facility that let's easily inspect the memory state. Being Java-based has another advantage, that it's relatively easy to integrate.

Another solution is one of standard JavaScript engines, e.g IE or Mozilla - those are supported by all libraries. Natively in JavaScript, it's fairly easy to capture the result of above examples, because all objects in JavaScript are hashmaps, so reading an object API is as easy as iterating over it's members with a for loop. The drawback is that it's impossible to read API of objects that have not been created yet. For example:

AnEvent = function(name, time, source) {
this.eventName = name;
this.time = time;
this.source = source;
this.send = function(object) {...};

So until someone calls new AnEvent(name, time, source), it's impossible to figure out the structure of the AnEvent type. The other problem with this solution is that only trusted code can be run. Any infinite loop would break it.

Tuesday, February 2, 2010

Looking thru the mirror

After a loaf of Java, bite of JavaScript and little bit of PHP in my most recent career, last week I headed to Poznan .Net Group meeting to see what are this guys doing up there.

Assuming you're a Java guy, you know who is who in Java world, you know what's JEE, you wait for Java7, can tell why NetBeans sucks. You meet a Java friend and together whine about Maven, Eclipse, EJB, then have a beer and next day all again.

And now there are those .Net folks. What are they up to? One guy there was from company of approx. 200 Java engineers. Only his (10 person?) team does .Net there. Oh my, are this two groups talking with each other during a lunch? That's what I was wondering on my way there.

And the meeting was fun. At first look, just as I had passed a magic mirror with applied "s/Java/.Net/". About 10 people in the room (quite like on our Java group), tense air, two topics: S#arp Architecture and PowerPivot review. I especially liked S#arp because it's kind of framework. PowerPivot on the other hand is actually a tool, powerful and good to know about, but I'm not going to use it or work on anything similar in near future.

The first speaker, started with a little history background of web applications, then did quick breakdown of all S#arp parts and finally small demo of what it does.

S#arp, as it was said, is a bunch of nice tools glued together, adhering to common conventions. There's NHibernate, TweetSharp, NUnit, N4, jQuery and couple more Nthings that I don't remember. It's a generative approach, where you customize prefabricated templates to produce some C# code. Generated stuff uses bunch of custom code based on various popular small tools.

So while you could basically do all of this by yourself, learn NUnit, N4, etc. etc., you can just focus on describing your model, and then get very basic unit tests, web application, data layer abtraction and something more with just one click.

So I'd be interested to learn about Java solution, where you edit a model, and get ready web application. I know I can use EMF, to easily get running Eclipse application, it generates tests skeleton, can customize templates. But fundamental difference between EMF and S#arp is that in EMF you have to buy everything (validation, data persistence, etc.) from one source, whereas S#arp adapts to already existing technologies and is mere MVC integration layer. Second, standard EMF doesn't generate web apps. Third, some JEE folks just don't buy code generation and EMF so maybe there are more arguments which such non-JEE guy as me doesn't understand.

The other intersting observation was IDE. There's no problem, like we once had on Java meeting where speaker nearly refused to show example, because we had only Eclipse and he works on NetBeans. Everyone uses VisualStudio. And actually some of the mentioned small tools integrates with VS if you copy one or two dlls here and there.

It's pretty much like joining JEE knowledge, JEE tools, EMF Runtime and EMF tools to work together. You get EMF tooling to create a model and then generate a standard JEE application, adhering to conventions, best practices, etc. This is what tons of JEE developers could like. With little knowledge of patterns, conventions, practices they'd be quickly making standard JEE apps adhering to best practices, conventions and patterns.

That's just a highlight of the meeting compared vs. my little Java knowledge. But there were also many little differences in group governance, people motivation, focus on trends and so on. I encourage anyone to try this excercise and look thru the mirror too.

Saturday, January 30, 2010

Wspólna lista poznańskich forów IT już jest

Już jest jedna wspólna lista poznańskich grup informatyków! Wszystkie wpisy są ładnie posegregowane by łatwo się zorientować, który pochodzi z JUGu, .Netu, itp. Na pierwszy rzut oka wygląda że największy ruch jest na grupie Javowej, ale może to tylko zbieg okoliczności.

Oczywiście nie wszystko jeszcze się udało. Np. poznańskim Linuksowcom szwankuje strona, adobowcy nie mają forum a jedynie bloga, grupy uczelniane (Politechniczne Booboo i Uniwersysteckie KINO) korzystają z uczelnianych list dyskusyjnych, gdzie jedynym sposobem nadążania za dyskusją jest zapisanie swojego e-maila - o RSS jeszcze nikt tam nie słyszał.

Link RSS: Poznan IT Groups.

Dla ciekawskich jest też jak to tam sobie działa.

Sunday, January 24, 2010

Co tam ciekawego w Poznaniu!?

Odkąd bardziej interesuję się javascriptem, odkrywam nową cechę społeczności javowej. Jest ona najbardziej zorganizowaną grupą programistów regularnie spotykających się w wielu miastach tylko po to by zdradzać kilka technicznych sekretów swoich warsztatów. Są ludzie z korporacji, studenci, konsultanci, startupowcy, naukowcy - niemal wszyscy. Większości nikt za przychodzenie nie płaci, czasem można zgarnąć książkę ale najczęściej jedynym plusem ze spotkania jest kilka nowych ciekawostek i znajomości.

A co wśród wyznawców innych języków? .Net-owcy, php-owcy, erlang-owcy (mieliby co gadać o nktalku:-), dynamiczni, itp, itp. a potem bazodanowcy, flaszowcy, linuksowcy (tu wiem: PLUG)? Powiedzmy, że wchodzę w nowy język/temat i mam setkę pytań - jak tu zacząć? Najprościej oczywiście na starych dobrych grupach dyskusyjnych, ale jak tu znaleźć kogoś w okolicy?

Stąd wpadł mi pomysł by zebrać do kupy wszystkich programistów i grupy z Poznania i okolicy. Docelowo chciałbym widzieć kalendarz ze wszystkimi techniczno/technologicznymi wydarzeniami w Poznaniu, listę wszystkich tweetererów z Poznania, zagregowany blog okolicznych bloggerów i na koniec, choć wg. mnie najważniejsze, łatwą nawigację do wszystkich lokalnych forów (przynajmniej w trybie read-only).

Na początek wstawiam listę wszystkich znanych mi grup dyskusyjnych z Poznania:

Poznan .Net Users Group:
Poznan Linux User Group: (Nie działa)
Poznan Adobe User Group: (btw. kilka dni temu mieli spotkanie!)
GIK: (tu niestety nie ma żadnej listy dyskusyjnej)

Następne w kolejności będzie zagregowanie forów, by łatwo śledzić co się na nich dzieje. (Może wystarczy odszukać adresy RSS?)

Pozostaje tylko pytanie do Was, drodzy czytelnicy. Znacie jeszcze jakieś fora w Poznaniu/okolicach? Czekam na linki w komentarzach!

Sunday, January 17, 2010

GeeCON 2010 - Call for papers

May will be great month to be in Poznan. We'll be having a biggest Java conference in Poland and eastern Europe. The list of speakers is already getting very interesting. If you will be around, consider visiting us. Below I'll paste the call for papers, specially that there's not much OSGi or Eclipse speakers yet.

There are also cool vids from last year, you might like to see.

GeeCON 2010 - Call for papers
We want you to share your knowledge with others during GeeCON!

We are interested in hosting lectures on subjects associated with Java
and software engineering, such as:

  • Java EE, OSGi, enterprise architecture patterns and best practices
  • rich internet applications (Flex, JavaFX) and Java Desktop applications
  • modern web frameworks (Wicket, Grails, JSF etc.)
  • domain specific languages
  • languages on the JVM (Groovy, JRuby, Scala, Clojure ...)
  • mobile computing (Android, Java ME)
  • JVM performance tuning
  • distributed computing
  • software quality assurance in the Java world (refactoring, automated tests, mutational test verification, static code analysis)
  • software configuration management (including tools like Maven, Gradle, Ant, Ivy)
  • agile methodologies
  • cloud computing

If you:

  • have experience in an interesting subject or a cutting-edge
  • want to share knowledge,
  • have good presentation skills,
don't hesitate! Prepare a short abstract about the topic you would
like to present during GeeCON and send it to us!

There are only a few rules:

  • call for papers starts on 2010-01-06 and ends 2010-02-28,
  • abstract should be about 250 words long and describe what you are
    willing to present,
  • abstract must be accompanied by a short technical and presentational
  • lecture will be 50 minutes long and will be given in English
  • presentation will be prepared using a provided GeeCON template,
  • use this form to send your submission (don't send it via email)

in case you have any questions, contact us at call-for-

Feel free to send as many proposals as you see fit. Please, contact us
if you have any questions or doubts regarding your submission.

See you at GeeCON!