java

Top 7 Reasons Why You Should Work for a Startup (clickbait intended)

It’s been a while since I’ve posted something here but as they say, desperate times… So as you might not know a lot has happened in my professional life since I wrote here. Last time I was getting ready to start a new job for Instaply, a startup based in the US but with an awesome team spread around the world. I worked one year with them, and then I was invited to be a coach for NEST’up Spring 2015. Then last month, I started a new job for another startup, based out of Brussels this time, called Take Eat Easy.

Just to get it out of the way, since the topic of this blog post is going to be about the advantages to join a startup, let me come back to the reasons why I left Instaply after just one year. It has nothing to do with the startup environment itself, and everything to do with the reason why I chose to go freelance in the first place: I love to choose the projects I work for and the people I work with. When one or the other becomes something I have to accomodate instead of something I fully enjoy, AND once I have tried everything in my power to make things go back to where they were at the beginning without success, I start listening for interesting new opportunities. That is exactly what happened here. I would have loved to keep working with those great developers. I didn’t believe enough in the project anymore to fully enjoy working on it. I tried everything I could to steer it back to where I would have believed 100% in it. I was not the only person to decide of course. I was offered a coaching position for a renowned startup accelerator I co-created, I moved on. The funny thing is that the first season of this same accelerator, 3 years ago, saw the birth of another startup: Take Eat Easy, yes, the same where I work now. Small world, right?

Now that we’ve got that out of the way, let’s get back to the present time now. When I joined Take Eat Easy, I made it clear that I didn’t just want to code, I wanted to have a greater impact on shaping the future of a business I really believed in: helping people eat better from the comfort of their home. So I joined as a VP of Engineering. If you want to know the difference with the role of CTO, you should read this article. So now I have the opportunity to keep building some software, but also to build a team with the best possible methodology and structure for the years to come. As a team builder, one of my main responsibilities is to grow the team, to recruit great developers. And that’s what brings me back to my blog.

Right now, we are looking for 3 key persons:

  • one or two Java backend developers to keep building our core system and make it stronger as we release our platform in multiple countries
  • one or two web frontend developers, familiar with Java (JSP, Spring MVC, etc.) but also very strong with HTML5, CSS and Javascript, to make our customer website and our internal tools completely ergonomic
  • one or two Android developers to bootstrap the development of our brand new mobile app, and help us with the development of our apps for restaurant managers and bike couriers, among other things

And I’m not gonna lie: I was expecting to get more applications. The fact is that we are looking for senior developers because we don’t have time to train newbies for now (sorry guys), and we need strong developers with enough autonomy and creativity to take matters into their own hands and really build the backbone of a great team. But still, I can’t help but wonder why we don’t get more applications.

First hypothesis: people just don’t know we’re hiring. Well at least now, you know (and your best developer friends will soon know, right?). I also published a few messages on targeted LinkedIn groups, there was a lot of press surrounding our recent funding round, and we do have our recruitment website where you can see our awesome industrial office space. But maybe it’s not enough.

Second hypothesis: the technologies we are working with are so commonplace in big corporations and institutions like the European Commission, that offer good paychecks and a comfortable 9-to-5 job, that developers are just too comfortable there to get interested in anything else. But I’ve been there, I’ve done that, and I know that working for those big institutions can look like a golden jail and eat your soul from the inside out.

Third hypothesis: startups are so rare in Belgium, that few developers actually know what it’s like to work for one, they don’t see all the benefits, and it sometimes looks too good to be true. So let me set the record straight and give you my top reasons why developing for a startup is so awesome (and of course, even more so for Take Eat Easy :oP )

Have an impact

More often than not, when I’ve worked for big companies, I never met the end users of the apps I worked on. Sometimes, the software I wrote never got to a real end user because the project was just dropped before the end (which tends to happen when a full waterfall development cycle takes a few years to complete before you realize your software is already out-of-phase with your market).

In a startup, not only can you see your final users, but you can meet them, touch them, feel their pain, and more importantly feel the joy and happiness that your software brings to their lives. When was the last time you could say that from the invoice checking ERP/SOA system your worked on (real world example)?

Learn some startup skills

I know so many developers who stay in their 9-to-5 job in a big company and save money for the big day when they will finally take the plunge and turn one of their million-dollar side project idea into a real business. I used to be one of those.

What if you actually learned some useful things while saving for your big coming out? What if you actually witnessed first hand what it takes to be in a startup rollercoaster before you build your own? What if you used this experience to see if you are actually CEO material, and in the process, put your full power to good use by helping a business you actually believe in? There actually is a middle ground between a boring dull job for a pharma company and creating your own startup: it’s called an exciting job for an existing and thriving startup.

Bonus: where are you more likely to meet your potential future cofounders, team mates and investors, at the European Commission or at the heart of the startup ecosystem?

NB: if you are already further down the line and you are planning to launch your own startup within a year, this doesn’t apply. Working for a startup is a long-term commitment and you will only benefit fully from it (and let’s face it, the startup will only benefit from your expertise) if you stay long enough.

Zero-bullshit

9-to-5 jobs are called that for a reason: so long as you clock in at 9 and clock out at 5, you’re good, no matter what you have really done in-between. If you do less than that, you can already feel the warm breath of your manager in your neck (and probably smell his bad armpits with this weather). And those companies are so much about appearance, that you have to disguise as a serious person, with suits and everything. And you have to attend meetings, watch boring Powerpoint presentations, play political games, and the list goes on forever.

Nothing like that in a startup, really. It’s pretty much like McDonald’s. Come as you are. Geeky t-shirts, flip flops, 3-day beard, whatever. So long as you do your job, you get results and produce awesome software, we don’t care how you look or when you come to the office. As a matter of fact, we know you are going to stay late, because you will love your job and your team mates so much that we will have to send you home! And no bullshit meetings or layers and layers of management. We are not here to justify our paycheck, we are here to get some shit done, and make the world a better place, one distributed database at a time (Silicon Valley pun intended). Anyway, you get my point.

It’s an investment

Whatever you do for a big company, where is the incentive to do your job better today than yesterday? But who am I kidding, if you are reading this your are probably such a perfectionist professional that you don’t need any incentive. But what about your colleagues?

In a funded startup, not only is the paycheck completely comparable to your current corporate one and probably even better, but you get one thing the big guys will never be able to offer you: stock options baby! I know, this is not a salary, and I am the first one to say it should not be bargained as one. It is merely a bonus. Some would even say it’s a gamble, and in some sense it is. But what do you call a bet in which you can influence the odds of successful outcome with your hard work, sweat and creative ideas? I call that a pretty good bet, one that won’t make you rich for sure, but might go a long way in setting you up for your own startup some day… or anything else for that matter. How about that?

Awesome colleagues

How many times have you complained about all those guys around you, who are not all bad, but have become so infatuated by such comfortable working conditions, that they have completely stopped questioning the status quo and the misery of their conditions. But you are stronger than that, right? You are still too young for that shit, huh?

Then how about working for a company that doesn’t settle for the average Joe Does-the-Job, but strives to only work with the most creative, no-bullshit software builders it can find? How about being part of a great team, and even participating in building it with all the great developers you have met throughout the years, and thus influence your stock options value even more?

Cool perks

Do you remember the last time you yelled at your computer because you still don’t understand why you get to build complex user interfaces and innovative backend systems on the same gear as Julie from accounting? And that chair, boy that annoying old chair that was probably already used by card punchers if you know what I mean, and has likely squeaked though Y2K bug times. And don’t get me started on those unbearable cubicles and that awful stuff they call food at the Sodexo joint downstairs (confess to me: when people ask you how it is, you still answer “it’s fine!” with an awkward smile). I’m barely exaggerating, admit it.

Of course, a startup is so much better on all those fronts. I needed a big 27-inch screen to do my iOS storyboarding wizardry properly, I got the green light for one in a couple of days, and now it’s proudly sitting on my desk. Inspiring creative work environment? CHECK! Awesome food delivered straight from the most trendy restaurants in Brussels? What else? (ok, the Take Eat Easy factor might help there). All those little thing that make you smile your way to work, along with Magic Assembly breaks, no-nonsense days-off policies, do you really need me to go on?

The (real) Agile way

I’m not talking about post-it fakery here. No “of course we do Agile! RUP is agile, right?”. Ever heard of ScrumFall? Remember those post-it notes that you ordered to migrate your project to Kanban, and that ended up arming your post-it war with your cellmates across the road, out of despair?

In a startup, Agile is not something you do to shake up your manager’s certainty, or to make your life as a developer less miserable in an Excel-driven management world. It’s a necessity. It’s the norm. It is what you do because it’s just the most efficient way to get shit done and to ship actual software out the freaking door and into the hands of your feedback-blowing users. Real Kanban with regular retrospectives with which you can customize the process to fit your team’s way of working in full collaboration (not against) a business that actually craves for your every line of juicy code.

 

That’s what a startup really looks like. And of course that’s what OUR startup really looks like, and will do even more so if you loved every advantage listed above and want to make them even more real by joining us.

Of course, I can already hear some of you in the back whisper: “oh, but that’s not all rosy, you will probably do crazy hours, and you will have a lot of responsibilities, and it might not work out in the end, it’s not safe out there, it’s a cutthroat jungle, and investors will make a lot more money than you, and your kids will see your sorry face a lot less, and yes, you will learn, but you will fail a lot to get there, and…”

I won’t deny. That’s all I have to say: I won’t deny any of that. I’ll just let you read it back out loud and leave you with that and my direct email address: sebastien.arbogast@takeeateasy.be

By Sébastien, ago

Top 5 reasons why you should consider Groovy and Grails for your enterprise software architecture right now

I’m so amazed when I see how so few companies are using Groovy and Grails right now, and are still using old stuff like Spring and Hibernate, that I thought I would jump in and do my share of educating. And why not give in to the fashion of top lists while I’m at it? So here it goes: if you are an enterprise software architect and you have a lot of Java in your world, you might want to read carefully what follows.

(more…)

By Sébastien, ago

Why Do I Hate Eclipse?

As a consultant, I’m very often forced to use Eclipse as a development environment, and every time I do, it’s such a pain for me that I can’t help complaining about the poorness of this thing. And every time I do, most of my team mates, who have been brainwashed by the monopolistic propaganda of Eclipse, just keep asking me what’s wrong with it. And sometimes it’s hard to explain because it’s really a matter of user experience. And each time I find a specific example, I get answers like “yeah, but that’s just one thing”, or “I’ve never had that, you’re not lucky”, or “this is just because you’re not used to the Eclipse way of doing things”, or even the worst one “maybe yes, but it’s free!”. Since when is “free” a feature?

Right now, I’m reading the SpringSource dm Server getting started guide, and I was very surprised to read that SpringSource guys, who aren’t exactly stupid, and seem very experienced with Eclipse itself as they have based all their development tools on it (Spring IDE, STS, etc.), talk about what they call the “Eclipse Dance”. I didn’t know about the expression but I’ve definitely danced it more than once: every now and then, Eclipse views get all mixed up, some views indicate errors in a file, while other views on the same file say everything is OK. Or you get a message saying that it cannot find a class where you have the source in front of your eyes. Or like now, I have 2 maven projects at the same level referencing the same parent POM, and one of the projects says it can’t find the parent artifact, whether the other one seems to find it without problem. And when that kind of things happen, the only thing to do is to try a combination of closing all projects and reopening them, clean all projects to force a clean build, or even restart the whole Eclipse workbench. WTF?

How can SpringSource support such a poorly designed environment while admitting such unacceptable bugs? Oh yeah right! It’s free, so everybody uses it. This is really the perfect example of when Open Source can also kill innovation instead of fostering it. It’s free so everybody uses it, including corporate customers, so all tool vendors base their tools on it (Spring IDE, Flex Builder, Weblogic Portal Workshop, etc.), so even more people use it (even if they have better tools in their bag), and we’re screwed.

I would love that framework vendors focus first on command-line integration with tools like Maven and Ant, and then provide IDE integration for a few popular environments, including Eclipse, Netbeans, and my personal choice, IntelliJ IDEA. This would reinforce competition between IDE vendors instead of killing it while considerably lowering the barrier to entry to their frameworks. Right now, SpringSource is lucky I really need to understand more about dm Server, because if it had been only for cusriosity’s sake, I would have given up already just because of the tight integration with this crappy Eclipse thing and all the pain I have to make it work consistently.

So if you’ve already been in that situation, and you start to think there’s gotta be a better way, try out IntelliJ IDEA.

PS: I’m not related to Jetbrains in any way. I just happen to be a very happy customer of theirs, happy to pay a few hundred bucks every year to get their latest version, because as a Jetbrains guy said it last year at Devoxx, “IntelliJ iDEA is the only IDE worth paying for.”

By Sébastien, ago

Talk Less, Do More

I’ve been a Java developer for almost 8 years now, I’ve used many frameworks and tools, Spring, Hibernate, EJB’s, Swing, etc. And a few years back, I started to look for a less verbose way to express concepts like business entities, services, workflows and so on. For some time, Model-Driven Architecture (MDA) has been the best answer I could find. But the learning curve and the difficulty to customize transformation patterns for specific setups, like a Flex front-end on a Spring back-end for example, have made me realize that this approach was somewhat limited by its UML foundation.

So I started looking for a better answer, and I thought I had found it with Language-Oriented Programming, the idea to decouple the structure, the syntax and the semantics of a language and ease the creation of Domain-Specific Languages in a very generic way. Unfortunately, as promising as it looks, it’s still in early stages of research and development and I needed a more immediate way to improve my productivity, my ability to do more with less words.

So I came back to something I had totally pushed aside till then: scripting languages. I’ve been “raised” with strongly and statically-typed languages since day 1 of my programming carrier: first Pascal, then Delphi, C++ and Java. And I always thought that scripting languages like PHP, and later Ruby were just tinkerer stuff for lazy hobbyist programmers, that didn’t take into account constraints like maintainability, robustness, readability, performance, etc. All those constraints I faced as a professional consultant. But a few weeks ago, I started to question my certainties and began wandering around PHP, Ruby, Python and others.

PHP, I’m using it at work on You And The World, it’s too hard to debug in a Flex/AMF setup and it’s really too permissive. As for Ruby, I like the ability to design DSLs but the syntax is definitely not intuitive enough for me. So now, I’m trying to learn more about Python, whose syntax seemed more familiar and maturity is reassuring. Everything seemed good until I read this single sentence in the documentation:

[…] classes in Python do not put an absolute barrier between definition and user, but rather rely on the politeness of the user not to “break into the definition.”

Come ooooon! Politeness of the user? You must be kidding right. In a corporate environment, when your code is likely to be reused and shared and refactored? I thought “hey, that’s probably just a provocative way to say that we Java developers tend to overdesign, and I know it’s true… so let’s read on…”. But unfortunately it proved to be much more than just a provocative sentence, since a few lines later:

In fact, nothing in Python makes it possible to enforce data hiding — it is all based upon convention.

OK. It took me a while to accept the argument that static typing can be too much of a cost in terms of verbosity compared to the poor protection it offers in terms of code correctness. But I said “OK, we’ll see how it looks when we come to real code”. But now they want me to forget about encapsulation too! What is the purpose of even writing a class then? What are you describing? A library of functions with a hidden first parameter? Is that it?

I mean, typing might be a unnecessary hurdle when writing unit test becomes much easier, but giving up on the behavior/state balance, the ability to describe what a class can do AND what it looks like, this is too much to ask.

So now what? Am I stuck between two extreme alternatives: either describe everything and waste energy doing it, or describe nothing a pray/ask for politeness?

And then I thought about LOP, and this interesting idea to decouple structure, syntax and semantics. After all, programming languages have entangled those three aspects for decades. And now both mainstream platforms (Java and .Net) are offering a variety of languages running on the same Virtual Machine. Isn’t that a first step in decoupling syntax on one side, structure and semantics on the other side?

Suddenly I’m starting to dream of a new syntax, far less verbose than the one of the Java programming language but with the same rigorous Object-Oriented structure, and the ability to run on all runtimes with different semantics…

What if the following Java code:

{code type=java}
public class TodoItem extends Item implements Synchronizable{
private String title;
public String getTitle(){return title;}
public void setTitle(String t){title=t;}

protected boolean done;

public TodoItem(String title){this.title=title;}

public void check(){done=true;}
}
{/code}

Could be rewritten like this:
{code}
+ class TodoItem > Item @ Synchronizable
– title
+ <-
return title
+ -> t
title = t

#done

init t
title = t;

+ check
done = true
{/code}

…or something similar ;o)

The key ideas being:

  • Keep all the key concepts of OOP: encapsulation, inheritance, polymorphism, composition
  • Remove static type declaration: I don’t care that my hammer has a wood or a steel handle, but I need to know it has a handle.
  • Replace long keywords by well-identified signs
  • Replace “{}” and “;” by indentation (Python-like)
  • Add simple property syntax (I love the way ActionScript does it)

In other words, I’m looking for a middle-path alternative between Java and Python, between waste and pray, between overdesign and politeness. Does anyone know of a language that offers that kind of compromise? Does anyone know if it has already been tested but has proven to be a dead-end for some reason?

By Sébastien, ago

The Flex, Spring and BlazeDS full stack on Adobe Developer Connection

The last part of the reedition of my article series about Flex and Spring has been published on the Adobe Developer Connection. This episode is the last one in this improved series so if you haven’t read it yet on my blog, I think the version I gave to ADC is better.

Episode 1
Episode 2
Episode 3

Enjoy!

By Sébastien, ago

MobiMap 1.0-RC2

I just released version 1.0-RC2 of MobiMap library. Amongst the features I’ve added are:

  • better icons for screen controls
  • better support for touch screen devices with a new zoom slider
  • all strings are now internationalized in French and English
  • a help screen with all the active shortcuts when you hit 5 numeric key
  • it is now possible to customize all shortcuts programmatically

More information on the official site.

And if you want to test a demo application using MobiMap component, just point your mobile browser to http://mobimap.epseelon.org/mobimap.jad

We’d love to hear your feedback.

By Sébastien, ago

My OSGi Learning Path (Part 1)

I’m more and more convinced that OSGi is going to change the way we develop enterprise applications. In a sense it’s funny because it’s been around for a while in embedded and client-side environment, and it’s only been reaching to us server-side developers for a few months. I think that the fact that the most popular Java component framework, ie Spring, jumped in with Spring OSGi (now Spring Dynamic Modules) has a lot to do with this new awareness. That and the growing interest for modularity and reusability encouraged by the Service-Oriented Architecture fashion. Yes, I agree that SOA has become yet another buzzword encompassing everything and nothing, depending on what software vendors sell to their naive customers. But if customers are ultimately willing to believe false promises, it might be because there is a gap in current technologies. Some see this gap as an opportunity for sales, developers see it as an opportunity for technology improvement. And I really see OSGi as THE technological answer to that and many other problems. Yes, OSGi might be server-side development’s 42!

Now, once you realize the importance OSGi is going to have in the years to come, the question is… sorry, the questions are why, what and how? Of course you could read the entire OSGi specification, but it would be like using a bulldozer to plant a flower. Fortunately for us, there are plenty of articles, blog posts and documents out there to help us understand how to deal with our delicate flower. Here is a possible learning path that will take you through a journey in OSGi world, why it’s useful, what it is, and how you can use it in your own projects.

Why is OSGi interesting?

Kirk Knoernschild wrote two excellent blog posts with sample code that is as simple as it can be and really gives a practical idea of what OSGi is all about.

    • The first one introduces the notion of a service in OSGi
    • The second one shows how you can really decouple the interface and its different implementations and dynamically switch from one implementation to another one

What I really like about those articles is that they use no external tools like Maven or Eclipse. Just plain text and Ant to compile. Just one thing that can be useful: you might want to download the latest version of Felix (1.0.4 at the time of this writing) and customize osgi/HelloWorld/config.properties (lines 31 to 34):

felix.auto.start.1= \
 file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.shell-1.0.1.jar \
  file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.shell.tui-1.0.1.jar \
 file:/Library/Apache/felix-1.0.4/bundle/org.apache.felix.bundlerepository-1.0.3.jar

Those are my own modifications because I downloaded Felix and installed it in /Library/Apache/felix-1.0.4 on my Mac. And of course you will have to adapt startfelix.sh (or startfelix.bat) as well:

java -Dfelix.config.properties=file:./config.properties -jar /Library/Apache/felix-1.0.4/bin/felix.jar

Finally, in the second article, at the time of this writing there is a mistake in the code of the manifest for service2. I’ve left a comment and hopefully Kirk will fix his code in the repository. HelloWorldSpec/service2/META-INF/Manifest.mf should look like this:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Hello Service Impl 2
Bundle-SymbolicName: helloserviceimpl2
Bundle-Version: 1.0.0
Bundle-Activator: com.extensiblejava.hello.service2.impl.HelloServiceImpl
Import-Package: org.osgi.framework, com.extensiblejava.hello.service

Then, following those two articles, Kirk modified HelloWorldSpec to integrate Spring Dynamic Modules and show what it brings to the table. More specifically, you can see that Spring Dynamic Modules makes it possible to externalize service registration and consumption in Spring configuration files and have service and client classes as simple POJO’s.

That’s it for the “why?”. I guess you understand why it can be interesting to use OSGi on the server-side by now. In the next article, I’ll try to give you a few links to identify what elements can make up your OSGi development environment.

By Sébastien, ago

You dreamt of it? SpringSource did it!

3 months ago, the day SpringSource announced their acquisition of Covalent, the company behind Tomcat, I knew they were up to something. I even talked about it with Andrew Glover for JavaWorld. And now it’s real: SpringSource has just announced SpringSource Application Platform.

First off, a few links around this announcement:

Now this is very exciting. That’s the kind of inspiring technologies that make me think of tens of ideas for new projects, new tools that were just impossible before and that could now become reality. Adobe Flex had the same effect of unleashing my software artist imagination. Now I’m starting to think about combining the user experience of Flex applications on top of the ease of management, deployment and extensibility of OSGi with SSAP. Jeez, we’re living an incredible period!

By Sébastien, ago

Flex, Spring and BlazeDS: the full stack! (Epilogue)

Thanks to Brian E. Fox, I managed to avoid duplication of Flex remoting configuration files in this project. It requires a bit of additional configuration and I hope that Maven will soon provide a simpler way to do this simple resource inheritance thing. But in the meantime, this one will work.

I’m going to update my four–article series to include those modifications, but for those of you who have already gone through it before the update, here are the exact modifications you need to make to the project you got at the end of Part 4.
(more…)

By Sébastien, ago

Flex, Spring and BlazeDS: the full stack! (Part 4) [updated]

[UPDATE] This article series has been reedited on the Adobe Developer Connection. For more information, see this post.

In the previous articles in this series, we did the boring stuff of setting up Spring, Hibernate and MySQL on a sample todo list server on one side, and we wrote a small useless Flex UI on the other side. In this article, we’re going to write the final UI and connect it with the Spring backend using BlazeDS. Let’s go!
(more…)

By Sébastien, ago