Wednesday, October 31, 2012

The title is sensationalist. All I've done is tweak a bit how we interface between GHCi and the Eclipse debugging framework. What that allows now (in the development version of EclipseFP) is to have expressions (in the Debug Expressions View) evaluated even if you're not stopped at a breakpoint.
So when you work directly in GHCi, you type in expressions to check the results. But when you change some code and hit :reload, your bindings are lost, you need to retype the expressions. EclipseFP does all that for you.

I've posted a video of a simple session in action on YouTube. It's my first video ever! It just shows a trivial arithmetic function being changed and how the result refreshes as soon as you select back the running program in the Debug view. Best viewed large...

Friday, October 26, 2012

I decided to release a new version of EclipseFP, 2.3.2. There also new versions of buildwrapper (0.6.2) and scion-browser (0.2.11) on hackage, even though they are not strictly required (but they compile under GHC 7.6).
This new minor releases offers some bug fixes and performance improvements. Hopefully the installation has been made easier (it is possible to install all helper executables from one place). The debugging mode has also been enhanced, with GHCi history support and the possibility to select expressions in the source code and add them to the Expressions view or see their current value in a popup (when stopped at a breakpoint).

As usual, just point your Eclipse to http://eclipsefp.sf.net/updates. The full release notes can be found here.

Lately I've been quite addicted to OpenAlchemist, a Tetris-like game developed by I think a couple of French developers (cocorico!). The code is in C++, there doesn't seem to be a clear API to integrate with the engine, the forums are closed, but I still wanted to write an AI for the game..

So I've written a little something in Haskell and posted it on Github just in case it's of interest to somebody. I basically use the Win32 API to capture the game window and save it as a BMP, then I use the bmp library to open the BMP, and some home grown image recognition to see which shapes are displayed on the screen. Then comes the "easy" part, checking the possible combinations and seeing which one yields the higher score. So far the AI hasn't beaten my own high score, so there's still work to do!

I'm still struggling with shape recognition sometimes, so this is an area that needs an improvement. I probably need to read up a bit on the proper algorithms that people have found to do this kind of things instead of just writing my own, but hey, one needs to have fun!

Tuesday, October 23, 2012

I've been asked if the EclipseFP debugger could provide stack traces. Links to great presentations about the subject were even presented! Simon Marlow's explanation of what can be done now regarding stack traces was great, but doesn't solve my problem: the debugging session in EclipseFP uses the GHCi debugger, basically sending GHCi commands and parsing the ouput, and Simon's new solutions require -prof flags, and hence don't work with GHCi.
For the time being I've done something that is not stack traces, but can provide some context when debugging, using the GHCi history. If when invoking a function in GHCi function, you start with :trace, then the :hist command gives you the last 50 evaluation steps. EclipseFP now calls :hist automatically on reaching a breakpoint and parses its output. It represents them as stack frames in the debug view, even that's not what they are. This way, clicking on them opens and select the relevant code, so hopefully you can get an idea of where you are and what you code is doing.
A screenshot showing the history on the program given as an example in the debugging article of the Monad Reader (PDF warning!):

This will be part of the EclipseFP 2.3.2 release, hopefully this will be helpful to some.

Friday, October 19, 2012

Warning! This is not a technical post about EclipseFP or Haskell in particular, but rather some ramblings...

I’m a
software programmer. I work mainly from home. I love it. But I’m aware that
very few job postings offer the possibility to work remotely, and that if ever
I have or want to change jobs, I will need to move somewhere else, where
there’s a decent job market, to be able to work.

Now, I
suppose it’s easy for me to work from home, for a variety of reasons:

I
have been working on the same project for a few years with success, so my
management can trust me to do the work well;

I
manage a small team of people I’ve known for a long time and that have worked,
like me, for years on the project, so instant messaging, emails, a few phone
calls and the occasional meeting in person is sufficient interaction: they know
what I expect from them, and for better or worse work mainly in their comfort
zone;

I
work in a company that has grown mainly by acquisitions so has development
centers all over the globe, in which taking time zones into account for
meetings is natural, for example;

I
like to think of myself as self-motivated, organized and committed, so I don’t
need somebody behind my back telling me to work harder ;

I
enjoy the technical work so I don’t want to be promoted to a management only
role, where office politics and being physically close to the movers and
shakers of the company matter.

A few of
these reasons are specific to me and my situation, but it seems that generally
speaking, a few factors could be seen as promoting working from home:

The
technology is here. At least in the western world, most houses have fast
internet access. We have email, instant messaging, phone and video over the
internet. We have distributed source control management. We have web interfaces
for most tools we may use. We have cloud computing and virtualization so you
can log into a remote machine and work on it as if it were local.

With
the wave of outsourcing, managers should be used to have remote workers, even
in different time zones. Of course there was a backlash against outsourcing,
but I think the bad experiences with it were more down to the unreasonable
expectations (pay less money, get more work done) than to the actual distance
between managers and workers.

Companies
may want to be seen as environment friendly. Encouraging people to commute
and/or move to big cities is not a good thing in that regard. I barely use the
car during the week now that I can work in my slippers.

Of course
I’m well aware of all the objections a company can raise.

How
could I pay a good salary to somebody I don’t see? But are you only judging the
value of an employee by the number of hours she puts in? The end result,
working code in a shipping product, can be evaluated the same.

How
can I build a team spirit if nobody is in the same room? Well, we’re talking
computer programmers here. Of course social interactions are good (and I get
plenty of that in my personal life, thank you), but I strive on writing good
code, making a successful product, and feeling I can satisfy customers and win
new ones. I don’t need to be in the same office as the sales people to have
that motivation. Meeting the people in the office from time to time is of
course OK, the cost of travel and some hotel nights is nothing compared to the
office lease and fuel savings.

How
safe is my code going to be if programmers log on from any kind of location?
Well, it happens that I have to travel (to a customer, to another office) so
the problem is there even if your employees are not traveling remotely most of
the time. Use efficient security procedures (the ones that don’t get in the way
of getting work done so that people don’t get so fed up with them that they try
to bypass them at all costs) and encrypted connections, I suppose…

How
do I train my new or junior staff? That is a real issue. If somebody needs to
be hand-held to get started, it won’t be doable remotely. So you may want to
organize a few face to face sessions between new recruits and senior employees
at the beginning. But when hiring experienced developers, this should not be an
issue. Your code and your processes are well documented, right?

What more can
we do to encourage companies to offer home working? Do we just need higher fuel
prices to that employees cannot afford commuting? I hope we can be a bit more
proactive. Can more technology help? Do we need more tools?

Integrating
IDEs with communication tools so that communicating over live code is easier

Helping
distributed design sessions using things like touch screens and motion capture
sensors to better communicate the hand gestures that sometimes help conveying
ideas better than word (but on the contrary, I sometimes feel that having to
put down an idea in word helps it make clearer, and a trace of that thought can
be kept)

Or do we
have the tools and just need to get used to them? Or is it just a shift in employee-employer
relationship that may happen slowly and can’t be rushed? In this case, we need
to push more stories like 37Signals, about how successful software companies
are hiring remote employees and loving it!