My thoughs on Kotlin

3 08 2011

As a JetBrain’s Fan boy

I’m totally fan of JetBrain’s products. I’m using IntelliJ since the 4.0 version, even I develop a plugin for it. And seriously guys, this people know A LOT of programming languages; JetBrains develop IDE’s for Java, Python, (J)Ruby, HTML, JavaScript, PHP (originally developed by the community) , Objective C/C++, and have plugins for Groovy, Scala, AspectJ, ActionScript/Flex, SQL, JSP (including EL and JSTL), ERB, HAML, LESS, SASS, XML, YAML, Velocity, FreeMarker, Django Templates, Clojure, CFML (same as PHP) and many others. (without count, .Net products)

The development API for those IDE’s is so powerful that the community already contribute with many others (Including some esoteric languages): Arc, Bash, Erlang (this plugin is developed in Scala, EPIC geek) Fantom (very good plugin, seems to be abandoned, 😦 ), Gosu, Go (exists plans to develop a stand alone IDE using the IntelliJ Community Edition), JFlex, Lua, OCaml, Scheme, Power Shell and many others. Those plugins vary in quality from WOW to Eww!!, but is a good indicator for the quality of the language support on JetBrains products.

But, also Kotlin isn’t the first language that JetBrains develop. BaseLanguage is the language that come with MPS (Meta Programming System). MPS is a implementation of Language Oriented Programming paradigm. In plain English with MPS you can develop your own DSL and the MPS IDE will give you support, How? Extending the BaseLangauge (or creating a new one if you want). MPS isn’t too mainstream (A Hipster tool) but is already battle tested. YouTrack The JetBrain’s issue tracker was developed with MPS.

I think that we’re in good hands, JetBrains have all the experience and the knowledge to create a very good language, and of course with SUPER COOL IDE support from day 0. Also the feedback of the community is HUGE in the Kotlin Site. If JetBrains could embrace the community and listen them, they could develop a very successful language.

As a Scala Fan boy

I love Scala, Scala is my new best friend. I learn in two years with Scala more Computer Science than in five years with Java. Scala is a beautiful language that never end to inspiring me and amazing me (also scaring me).  Since I develop with Scala I’m a better developer; my code, even in others languages, seems to be more thread safe, more functional; but also Scala makes me a better son, citizen  and brother. Scala will lead us to a new golden age of prosperity and peace, a new renaissance of arts and philosophy. A beautiful new world.

But, let’s face the truth (please brothers of the Scala church, don’t kill me as a blasphemous) Scala’s complexity isn’t a Myth. (But I don’t agree with Gavin King)

Let me explain. If you come from a first world country with a very good High School program and Computer Science program like Swiss, Sweden or Norway; Scala isn’t complicated, but for people like me, that come from a third world country, with a Educational System “a little below the average” is complicated. I found myself studying countless hours to have “a little below the average” proficiency with Scala, I’m not complaining, was a VERY fun time, but, seriously guys is complicated.

Scala is more complicated than Java. Sure, you can use Scala as better Java, but is like buy a Lamborghini Gallardo to recharge your iPod, yes it’s works, but you’re losing a lot of features. In the other hand Kotlin IS a better Java, with good additions. A Java developer will be proficient in Kotlin in a fraction of the time, compared with Scala.

But Scala and Kotlin don’t need to be mortal enemies, If we can achieve a good interoperability between Kotlin, Java and Scala, we can have polyglot projects, so we can use the right language for the right type of problem. Also if you want to learn Scala a very natural way will be Java -> Kotlin -> Scala.

As an IntelliJ Scala plugin user

I think that the Scala support IntelliJ support is very good. Some great names in the Scala community are using IntelliJ and they are happy with it. Some FUD spread around the community with the announce of Kotlin thinking that maybe JetBrains will stop the development of the Scala plugin. Guys, this is the real world; the Scala plugin helps JetBrains to sale many IntelliJ licenses… JetBrains never will stop to develop the plugin as long as be good for business. Period

As a IntelliJ Power user

Obviously I use IntelliJ every day, but also I develop plugins. If JetBrains could use Kotlin to be more efficient in their developments all the users will win. But also they can test their new toy in a very hard scenario (Believe me guys, IDE’s are on of the most challenging scenarios for a language, and a developer).

As a business man

I have my own company (an one-man-army operation) I’m the Chairman, CEO, CTO, Sales manager, Development manager, Help Desk operator, architect, developer and tester. If I want to survive competing with other companies (big and small) I need a extra advantage, a secret weapon. My secret weapons are my tools (for more info on the subject you can read this post from Paul Graham). With IntelliJ, Spring Framework, Spring Integration and others, I actually defeat some bigger companies, with more developers, resources and money; delivering projects in a fraction of the time and costs with more quality. Scala provides me a huge competitive advantage… as long as I work alone.

But my little baby is growing, in less than a year I’ll  contract a few developers to achieve more bigger projects. Teaching Scala to a development team could be very challenging and frustrating and I COULD lose part of my advantage. But Kotlin seems to be a safer bet, More similar to Java, better integration, better IDE support, a huge productivity boost compared to Java… Kotlin could give more business value than Scala… heartbreaking history but true

But also if the language is successful (and have all the factors to be a success) there’s a lot of opportunity business waiting for us: Books, conferences, seminars, courses, libraries, tools, frameworks, certifications, t-shirts, mousepads, mugs and others, in fact a new beautiful world.

Advertisements




Flex on Java:Review

8 09 2010

The people of Manning books give a MEAP copy of “Flex on Java” from Bernerd Allmon and Jeremy Anderson

In my company we are developing an ERP for a mid-size company dedicated to sale construction supplies on Leticia, Colombia. The application is a port from a Seam based application to a Flex/Spring application (BTW, Seam is a HORRIBLE framework, avoid it  if you can). So this is a great opportunity to review this book

First of all, the copy that I have is MEAP version so, this is not the final book and can contain some rough cuts and unpolished parts (if I can obtain the final version I’ll update this review)

Chapter 1:Some Flex with your Java?: A general introduction to the main topics of Flex and, of course, Java. A nice introduction for the rookie, but I don’t think that a rookie want to read this book. Flex and Java are big Behemoths and think to dominate both with just one book is silly. Also we have our first “Hello World!”, and IMHO the main problem of this book: (actually, not so relevant) The majority of the example codes aren’t in the last versions of the frameworks.

Chapter 2:Beginning with Java: This chapter cover the development of a Java Web Application with AppFuse (I read about this framework but I never use before) and Maven, once more time good information for the Rookie (Including how to install a JDK, yes, you read well). The application expose some WebServices and have the DAO Layer with Hibernate, the IoC with Spring and the Web Layer with Struts and JSP. Thumbs Up for no including IDE related content

Chapter 3:Getting Rich with Flex: Very good chapter, nice examples, and a valuable information for all the developers that are new in Flex, although don’t replace a good book in Flex, contains enough information to start and see the power of this framework. Thumbs Up for don’t use Flash Builder.

Chapter 4:Connecting to Web Services: This chapter is worth of the total costs of the book. The code quality are amazing, as never see before on others Flex books. The authors introduce the MVP (Model View Presenter) Pattern, a good way of organizing the code of a RIA. Although I never use the MVP is very nice to see a good example of how you can organize the code to call WebService/RemoteObject.

If you, like me, are not new to Flex and Server communication you’ll know that all the examples in the web and in the books use the <mx:RemoteObject> tag, very well for small examples but when your application grows up you’ll have a lot of copy-n-paste code in all the application. Well this chapter teach you how avoid this nightmare.

Chapter 5:BlazeDS Remoting and Logging: This chapter cover the Spring Flex project in very detailed way. For me this is OK, I’m a fan of Spring ( I’m  SpringSource Certified Spring Professional) but not all the developers love Spring. So, will be nice if the book cover another options like GraniteDS and integrations with EJB3 and Seam (The HORROR). Thumbs down for don’t including information about Exception Translators and the proper way to manage them

Chapter 6: Flex Messaging: Messaging is one of the more powerful features on Flex. This chapter have a LOT of technical details, is very deep and not for the faint of heart. But if you’re using Flex and Java, surely you’re not of them, right?

Chapter 7:Securing and personalizing your application: Spring Security deserve a book for his own, but this chapter makes a good work explaining the basics of Spring Security and his integration with Flex. Good examples and good theory, much better than the Spring Flex documentation

Chapter 8:Charting with Degrafa: This is the chapter that I enjoy less, Why? ’cause Degrada only works in Flex 2 and 3, and my current projects are on Flex 4, however AFAIK Degrafa is integrated now with Flex 4, so, hypothetically speaking, the theory in this chapter will help you with graphics on Flex 4.

Chapter 9:Desktop 2.0 with AIR: Great Chapter, AIR is a very compelling technology, and is huge plus if you can turn your Flex Web App in AIR Desktop App, but don’t lies yourself, most of the times this is Phantom requirement (A requirement that don’t exists), so Choosing Flex ’cause you can make Desktop apps easily when your app don’t have this requirement is a no-no.

Chapter 10:Testing your Flex application:Unit Testing is a requirement on all modern application development cycle. Flex Unit Testing is not very different from Unit Testing on other languages, so if you already knows how to do Unit Testing, you will dominate Flex Unit Testing in a breeze. This Chapter also covers Continuous Integration with Hudson Server, another hot topic (BTW I prefer TeamCity from JetBrains)

Chapter 11:Flex on Grails: Grails, my deadliest enemy, we meet again. You hate me, and I hate you… jokes apart, seriously, I’m not able to run any Grails example, and for my own mental health I don’t make the example in this chapter, but the code seems pretty easy, (Grails code is very easy, if it works is another question) but don’t expect that Grails auto-magically generates MXML code, so it’s not reduce drastically the amount of work that you need to do a mid size app.

Conclusion: Flex on Java is a very well written book, the code examples have a great quality and are production-ready, a very rare characteristic in programming books.

I like:

  • Code quality
  • Explanations on some hard topics
  • IDE-Agnostic

Don’t Like:

  • The book use some outdated libraries
  • Some important topics aren’t well covered
  • Don’t cover other connection options apart from WS and BlazeDS

NOTE: 9/10





IntelliJ IdeaX: First Impressions

28 08 2010

I’m an absolute fanboy of all JetBrains Products. And now I’ll write mi first impressions on IdeaX, the last (and yet not final) version of IntelliJ.

  • First of all, this is BY FAR the best EAP (Early access program, by definition is more buggy than a beta version) version of IntelliJ, very stable, much more responsive and quick that the 9.0.3 version.
  • The UI have many improvements on Mac OS X, better status bar, very beautiful scroll bars and Open file dialog
  • ActionScript and Flex have a good looking new icons and many improvements on refactoring and intentions like delete unused namespaces declaration on MXML (this works on other *xml files too)
  • The editor now have a ‘soft wrap’ function
  • The database console now use a editor tab for queries, but right now don’t have auto-completion of table and columns names.
  • Support for LESS and SASS
  • Ruby and Python plugin have the same features of the latest RubyMine and PyCharm products
  • Not related to IdeaX itself, but JetBrains is making a good work on plugin development documentation, as plugin developer I’m very happy whit this, and of course, we’ll see a lot of new plugins in the future.

Seems like the JetBrains friends are making a good work with their flagship product, surely this new release will be an EPIC WIN for all IntelliJ Users





Play, Roo and a little of Django

12 01 2010

I start my own development and consulting startup-one-man-army company, a risky move on this times, but I hope that will generate profits in this year and in the nexts.

Weapons and choices

As developers, all we have a set of weapons to defeat different enemies, seasoned developers know that non exists a golden hammer, and different problems require different tools, even different mindsets.

Coming from the “Enterprise” world I develop a skills set for kill “big behemoth” projects, my tools include Stripes/Flex/Spring and I’m very comfortable with all them.

But in the small startup kingdom is very hard that you will develop a “big behemoth” projects in the first months or years (until you build a good name for your company), so you will develop small web apps with little requirements, and this is not bad at all, you can make a good profit, if you are smart and have good connections.

But trying to develop a small app, with Stripes/Flex/Spring, seems to be a little… overkill and don’t lie yourself, is possible that you spend a day (even a couple of days) setting the whole enchilada (xmls, libs and all the stuff that you need); this is not the worst thing, (but could be better) in a “big behemoth” with lot of tricky requirements (this tools give you incredible power and flexibility with a reasonable cost).  But in the small apps kingdom a couple of days is too much, and when you realize that you don’t need all the fancy stuff is worst, so I start to evaluate some other options.

The usual suspects

In the Java developer community mindset when you talk about productivity (wherever that means) two names shine among others JRuby on Rails and Grails.

Few years ago Ruby on Rails was the king of the hype, conferences, book, developers of all the world screaming “Java is Dead” and praising his new productivity messiah (wherever that means) whom would lead to the promise land. But them few stories from the trenches show that “The Emperor’s New Clothes” are too invisible for some guys. Right now the RoR community is more mature (or I think so) and Ruby on Rails seems to be good enough, but I think that I’ll wait to the Rails/Merb merge to take a look. In the other hand the JRuby on Rails seems to have less “Rock Star” attitude (Disclaimer: I’m writing this based on the blogs and articles that I read, I’m trying RoR but no more than a few tutorials and no serious project) .

Grails is the Java (or JVM) community response to RoR phenomenon, Grails right now have a lot of momentum and now is under the SpringSource umbrella, with lot of press attention and good community support. Take a look, I say; Groovy is nice language, I say; but, shame on me, I’m not able to run the simplest tutorials, lot of strange (and the worst, non-deterministic) errors spawn everywhere and my confidence in Grails died drowned in a pool of EOF exceptions (and other random things), Maybe in the future I’ll revisited Grails, maybe.

The new kids on the block

So I take a look to other JVM alternatives:

Django/Jython

I like Python, is good language, and the Jython implementation is really nice too, a lot of Python libs run very well with Jython including Django.

Django is a very nice framework, extremely well documented, very logical, little or no magic, nice ORM (I don’t like the ORM’s anyway, but this is nice),and have a set of apps (plugins in other frameworks) that let you build a standard web app with little cost.

The Django/Jython integration is very good, and his author (@leosoto) is a smart and nice guy, the main problem for me is his performance; each request represent a small peak in the processor performance, that obviously will be corrected with little hacks in the next versions. Django/Jython is good option to Java developers looking for a good RAD (when I was young the first thing that you think when you read this word was Visual Basic 6, ah the good ol’ times) framework.

Spring Roo

First of all I’m a huge fan of Spring related projects, even I take the Spring Core certification exam and pass with a shiny 94% (seems that I’m the first Colombian with this certification), so my opinion I could be a little biased.

Spring Roo is a project that aims to give productivity (wherever that means) to the Java ecosystem.

Roo have a nice shell interface with lot of options and good documentation, This shell let you to create a new maven project in matter of seconds, all correctly configured, nice start.

Then you can build your entities with the shell (a la RoR) and the horror begins. Roo will generate your class, annotated with Roo annotations and a bunch of *.aj files (AspectJ files) that seems (I’m not expert in AspectJ) that only add methods (getter, setter, toString and some static methods for queries with JPA) to the class (not AOP stuff). I never like code generation tools (if you, like me, try the JBuilder 9-X ($5000) EJB 2.0 app-from-database stuff, you know what I’m talking about), for me is like a glorified “copy-n-paste”. The only valuable thing that code generation tools bring is for teach to junior programmers what is smell code.

But the *.aj code that Roo generate seems to be not bad all, but who know? all the code analysis tools that I know don’t work on *.aj, shame on me. So you can make changes on Java class, but don’t expect that compile outside Roo (or maven), but I’m too afraid to change the *.aj files (one of the worst things of code generation tools) that seems that a dead end road

Not only that, you could generate a CRUD GUI based on JSPX and Spring @MVC (Obviously with all the *.aj stuff), but IMHO, Even with the Spring @MVC (that corrected many things like the horrible inheritance tree) included in the 2.5 version, Spring MVC is by far the most unnecessary part of Spring Framework, if Java have a thing this is MVC frameworks (good or bad), we don’t need another one, PERIOD. For me, used to Stripes, Spring @MVC seems very bloated with lot of code even for simple things. In theory you can make an Add On that build your  GUI in other technology, but theres no documentation right now.

Other thing that I don’t like is that the dynamic client parts are implemented with Spring JS that seems like a Dojo wrapper or something like that, well is pretty hard to know ’cause the documentation is near to nothing (a rare thing in a Spring project).

For me Roo will be almost perfect with a Stripes Add On (maybe I’ll make it in the future) and an option that “push” all the *.aj methods in the Java File… but wait a minute this seems a lot like my “BFG 9000” stack to kill “big behemoth”…. never mind

Play Framework

Play is a mind-blowing/fresh-air for Java ecosystem, totally different from all the stuff that exists in Java.

First of all don’t need a Servlet container to run, or compile, and you don’t see the Servlet API (????) and break some doctrinal rules that all Java developers know (public fields, Model classes extends from a Framework class, strong procedural flavor and others). Those engineering trade-offs could scare some guys, but at the end the framework is very solid

IMHO Play Framework is heavily inspired on Django, but have some things that are more polished that Django for example the absence of Forms (that are a little rough) , the routes seem more polished and the template language is a little more powerful (based on Groovy).

In the other hand, Play don’t have all the modules (apps) that Django have, and of course have less momentum.

In future releases, Play Framework will support Scala as development language, that seems like a very intelligent movement, and who knows maybe we’ll see Groovy, JRuby or Jython as development language (or crazy things like Jaskell or Clojure)

Play is a really good framework and I see myself in the future using Play a lot, (maybe I’ll write a plugin for IntelliJ).

Conclusions

I’ll invest some time on Play Framework in the next few months, but is a community driven framework, so is possible that don’t have the fuel to be a mainstream Framework. In the other hand Roo could be better in a near future with some additions, and have the financial support from VMWare, so is almost guaranteed that Roo will be a success in the middle size projects.





IntelliJ Community Edition

16 10 2009

IntelliJ Community Edition





Scala on Stripes/Spring(II)

26 07 2009

Well the past chapter was very well received

Now we will continue with the DAO layer, and will learn more advanced Scala concepts

The DAO Layer

My friends know that I’m a “SQL Boy” I never need to learn ORM (I try many times, but the laziness beat me) so I’ll use Spring JDBC. If you don’t know this technology I’ll encourage you too take a look, this is one of the best parts of Spring. Spring JDBC take out the pain of JDBC in a very easy way, in fact I participate on a project where we migrate a bunch of Classic JDBC DAO’s for Spring DAO’s and the code was reduced in a 70%.

ScalaSimpleJdbcDaoSupport.scala

This class is a Support Class that extend SimpleJdbcDaoSupport to make more easy the work with Scala. In this class we are writing a little utility function in order to provide support for the methods with (Object… args) that SimpleJdbcTemplate have. Also we are writing some functions to wrap the SimpleJdbcTemplate; in a Real Case Scenario you need to write a lot of methods more

package com.simpletasks.dao.impl
import java.util.List
import org.springframework.jdbc.core.simple.{SimpleJdbcDaoSupport, ParameterizedRowMapper}
abstract class ScalaSimpleJdbcDaoSupport extends SimpleJdbcDaoSupport {
//
private def buildObjectArray(params: Any*): Array[Object] =     params.map(_.asInstanceOf[Object]).toArray
//
def queryForObject[T](sql: String, mapper: ParameterizedRowMapper[T], params: Any*): T =
getSimpleJdbcTemplate.queryForObject(sql, mapper, buildObjectArray(params: _*))
//
def query[T](sql: String, mapper: ParameterizedRowMapper[T], params: Any*): List[T] =
getSimpleJdbcTemplate.query(sql, mapper, buildObjectArray(params: _*))
//
def update(sql: String, params: Any*): Int =
getSimpleJdbcTemplate.update(sql, buildObjectArray(params: _*))
}

  • line 04 abstract: Same as Java
  • line 07 Any: Any is Scala as Object is a Java, all the Scala Classes including Basic Types are subclasses of Any
  • line 07 Repeated Parameters: The Asterisk (*) symbol is like Ellipsis/Varags (…) in Java. This means that you could add the parameters that you want, but is different in Java in some ways first of all, In Java you can call a method with an Array of the same type of the varargs argument, this isn’t possible in Scala; the second difference, In Java, in the method body the varargs argument is an Array, in Scala is a Seq. Seq is the base for a bunch of Collections in Scala, and provide some nice functions
  • line 07 Arrays: the Array in Scala is different from the Java Array; first of all the declaration type:
    In JavaString[]in ScalaArray[String]second, the access
    In JavamyArray[0]In ScalamyArray(0)Third, the implicit constructor
    In Java{0,1,2,3,4,5}In ScalaArray(0,1,2,3,4,5)
  • line 08 map function: the map function return a new Seq (remember that Scala is a OO/functional language, so you will be a lot of immutable classes like this) after applying some algorithm to all his members
  • line 08 High order functions:: A HOT feature, High order functions are lovely functions that take functions as parameters and/or return functions. (Geek Fun). In this case map take a function that will be applied in all the Seq’s members, (in our case, we are casting all the members to Object) this type of functions are very common in Scala Collections and produce a very neat and elegant code
  • line 08 The Placeholder strikes back: Our friend is representing the Seq member that we are casting.
  • line 08 Casting: The casting in Scala is a function invocation
  • line 08 Square Braces []: Most of the time that you’ll see Square Braces ([]) in Scala are around a Type, in fact this is the way that we define Type parameterization (Generics in Java) for that reason we declare Array[String] instead of String[]
  • line 08 (again) toArray function: toArray is a function that convert this little Seq in an Array (pretty evident), Look that I call this function without parenthesis.
  • line 10 Type parameterization [T]: This is the equivalent to <T> in Java, but Scala Type parameterization have enough power (and beautiful concepts like, variance, co-variance and contra-variance, I told you Scala is a funny language) too put Java Generics in shame (Martin Odersky, The Scala Father was the co-designer of Java Generics). But… sorry the whole power of Type Parameterization is outside of the scope of this humble tutorial.
  • line 13 : _* This is a little “syntactic hack”, if we call our function buildObjectArray with the params Seq, we are passing the Seq and not the Seq members. with : _*, we are passing the members one by one.

Well A lot of concepts for a simple class. This is all for now, in the next chapter we will use this class and learn about Traits, Bye, bye.





Wise Java LOLcat take a SUN bath…

16 07 2009
Wise Java LOLCat take a SUN bath...

Wise Java LOLCat take a SUN bath...