Angel \”Java\” Lopez on Blog

April 15, 2014

End Of Iteration 2014w15

Previous Post

Code Generation

I wrote new tasks, templates using my AjGenesis code generation tool. I create a simple:

to generate a Django web site, with admin page. The code generation creates the model, and admin feature allows you to edit the data, using Sqlite. It’s simple, but it is working. Next steps: create custom views, and a new project to generate Flask web site.

I added text area input fields to the project that generates Express/Node.js web site from a model. Next steps: client-side validation, better server code organization, some initial tests.

I want to integrate these tools in a online app, so I started to have a web site that generate codes from a model, defined at client side. You will select technology (Express, PHP, Sinatra, Django, Flask, …), the models (mainly, entities like: customer, supplier, department, employee, invoice… ), the database, the features (multiple pages, single page, angular? backbone? other?, REST API?, phonegap wrapper?), and voila. A zip will be generated with the generated solution. That is, code generation as a service. Maybe I could add an API to be externally consumed.


I added a Flask web site example, work in progress, to my Python Samples:

I will use as a basis for my AjGenesis code generation version for Flask web sites.

Actor Model in C#

I refactored my project

an Akka-like actor model implemented in C#. Now, I have a mailbox per actor, but the actor message process is executed consuming task from a queue, with n thread launched by the initial actor system. It was good to see such refactor working: all is in place, now. It is a proof that you don’t need to design everything before coding. If you follow TDD (Test-Driven Development) new ideas (or old ideas that have not implemented yet) can be added without much effort.

Erlang in C#

I started to add serialization of message to my project

As usual, I started simple, using TDD: write input and out channel, using tests, red to green, refactoring. Instead of consuming an external library for serialization, I wrote a simple code, towards my first use case of distributed application. When the use case will be in place, I could start to think about other implementation path.

Google Code Jam

Past Saturday, I participated in Google Code Jam, Qualification Round. My code, usually written following TDD:

The Minesweeper problem is the tricky one. I should add the description of the problems, copying it from the original site.


I added some code kata tests to my JavaScript samples I added metadata macro readind go my Clojure in C# I started to add type checking in my node tree for Scala in C# I added qualified name evaluation to my Rust interpreter in JavaScript I worked on two non-public projects, too.

More fun is coming.

Keep tuned!

Angel “Java” Lopez

March 17, 2014

End Of Iteration 2014w11

Previous Post
Next Post


I finished my presentation about Node.js Distributed Applications:

Last week I gave this talk at the JSConf Uruguay Great days, interesting people, projects and ideas. I should post about my experience. In this talk I mentioned my projects:

And I did a quick description of some other basic projects I used to build the demos:


I updated my project

Now it has to samples: one, with position evaluation at browser, and another with position evalution at server side. Next steps: add worker nodes, at server side, to distributed the position evaluation, maybe with a tree search in many levels (now it explores 2 plies), or more levels using montecarlo.


After talking with @LostOracle at JSConfUy, I started an interpreter for Rust Language, in JavaScript:

The hello world is working:

I use and updated my grammar generator

Dog fooding is good!


I added new rules and some refactor to my projects:

I want to add a JavaScript application running at client side, to cover the main use case of Preciosa Project.

I worked on two non-public projects. Now, I’m back at Buenos Aires. More fun is comming!

Keep tuned!

Angel “Java” Lopez

February 22, 2014

Make It Work, Make It Right, Make It Fast

Filed under: Programming, Software Development, Test-Driven Development — ajlopez @ 5:05 pm

Years ago, I read this statement, applied to software development:

”Make It Work, Make It Right, Make It Fast”

I don’t remember the source. It is attributed to Kent Beck, but apparently, there are precedents. Read:

In the last decade, I started to understand the three-part statement, and I really think my software development skills were improved adopting this way of doing programming. Somehow is related to TDD (Test-Driven Development) but there are different things, and can be applied in a wider context. Let review what I think about each part, and how I apply them everyday.

Make It Work

Yes, instead of trying to do “THE RIGHT” thing from the beginning, I put my effort in having a working thing (a function, a method in a test, a use case branch, a user interface and experience). I don’t bother about the inner improvements, or about applying all the patterns from the book. I write code that works. Simple, working code. Following this advice, I can write simple code, and I can start to understand the underlying problem. If the product is use case branch (not a full use case), the working output  can shed light on the business model, and even end user feedback can be applied in early stage.

However, if I tried to do the right thing, I could waste my time and effort in something that is not what the project needs.

There is an special case: “make it work” is an essential of TDD second step, make the test go green.

Make It Right

Only when I have a working piece of software, then I’m back to improve it. Removing code duplication, applying the patterns in context (not only the patterns by the book), exploring new implementations. This is the opportunity to decrease or to remove any technical debt, any relic of toxic code. If something is convolute, go and write more straightforward code.

When the product is code written with TDD, I apply this advice at refactoring step. TDD workflow and cycle helps me to have a controlled technical debt amount. And having all the tests, now I can explore with confidence alternative internal implementations, without pain. It is really a creative step. Some programmers think that TDD puts a damper on creativity, but on the contrary, I see this two steps as a form of exercise it.

Make It Fast

Only then I worry about the speed of execution. There are so many factors that can influence it, that I only take care when a have a clear and working implementation. If you tend to write code in the previous phases thinking “this code is faster code”, stop doing that. I don’t know if a method is faster enough or not, without having a clear use case that needs performance improvement, and without having speed measured before optimization. Don’t optimize what it’s not measured.

Sometimes, I met project with the wrong decisions already done: someone added stored procedures, because “stored procedures are faster”, without any evidence of such assertion, without any performance suite that could support the statement. And then, a convoluted stored procedure, with lot of domain logic, start to emerge in the middle of the system. Even worse: without any test.

So, after practicing these precepts in my personal and professional projects, I’m a big proponent of following them. It is a pleasure to see how an idea grows up until become a concrete and solid library or system.

More fun is coming.

Keep tuned!

Angel “Java” Lopez

January 16, 2014

TDD Rocks! (9) JavaScript and Node.Js

Filed under: JavaScript, NodeJs, Test-Driven Development, Video — ajlopez @ 6:20 pm

Previous post

Thanks to JavaScript Meetup group at Buenos Aires, I gave an introductory talk about JavaScript and Test-Driven Development, using Node.js. The sample is basic, but I hope it is an starting point to appreciate the goodness of TDD workflow in JavaScript development.

The meetup group link:

My talk in “Anglish”:

My presentation:


Full post in Spanish with additional video and text in Spanish.

Keep tuned!

Angel “Java” Lopez

December 28, 2013

TDD Rocks! (8) SharpBase in C#

Filed under: C Sharp, Google, Open Source Projects, ShapBase, Test-Driven Development, Video — ajlopez @ 6:24 pm

Previous Post
Previous Post with C#
Next Post

I recorded a new Google Hangout about using TDD (Test-Driven Development) workflow in Visual Studio 2010 and C#, writing my in-memory database project, SharpBase.

The video at:

This time I implemented a Column class. It was not need in previous tests. But now, I want to have the use case of having an autonumeric column, I added tests and functionality to cover that feature. I didn’t design all at advance. I designed the solution test by test, use case by use case. Maybe, in some point, I would apply a surgical refactor/redesign, but now, I have the test battery to support such change.

This is the last video about SharpBase. Since now, I will update directly the GitHub repo. You can check:

Maybe, I will record a new exercise, but in Spanish: an MVC application.

Keep tuned!

Angel “Java” Lopez

December 21, 2013

TDD Rocks! (7) OStore With JavaScript/Node.Js

Filed under: Google, JavaScript, NodeJs, Test-Driven Development, Video — ajlopez @ 6:35 pm

Previous Post
Previous Post with JavaScript/Node.js
Next Post

I published a new Google Hangout session, showing how I’m working on project OStore, using TDD Workflow:


In this sample, I’m not learning JavaScript, I already known it. I use the minimal code, in this case the module assert, built-in in Node.js. I sacrifice the isolation of test to gain in simplicity.

In this session, I implemented a find methods a la query by example, like in MongoDb. Now, it is returning an array of JavaScript objects. I could refactor it to return a cursor. Then, the cursor could retrieve millions of records, without using an array as memory.

But you know my workflow: baby steps, make it works, then, make it right, make i fast. In other project I’m reproducing MongoDB behavior directrly in in-process JavaScript.

Keep tuned!

Angel “Java” Lopez

December 1, 2013

TDD Rocks! (6) Playing with Ruby

Filed under: Google, Open Source Projects, Ruby, Test-Driven Development, Video — ajlopez @ 3:34 pm

Previous Post
Previous Post with Ruby

I’m still learning Ruby. To practice the language, I’m writing a Tokenizer using my TDD (Test-Driven Development) workflow.

A new video at

I did two redesigns:

- To provide the text to tokenize in the tokenizer constructor

- Rename getTokens methods to a more "rubyist” name get_tokens

After those redesigns, I dived into a big implementation refactor. Maybe, I had to avoid that work, or split it in more manageable pieces. At the end, I survived, and the tokenizer implementation is started to emerge. You can check another of my implementations, in JavaScript/NodeJs:

The Ruby version is at:

Keep tuned!

Angel “Java” Lopez

November 30, 2013

TDD Rocks! (5) SharpBase in C#

Filed under: C Sharp, Google, Open Source Projects, ShapBase, Test-Driven Development, Video — ajlopez @ 2:01 pm

Previous Post
Next Post
Next Post with C#

I’m coding SharpBase, documenting my TDD workflow using Google Hangouts. The new video at:

I implemented how to insert a row, given its values the method returns the new row. In this first test I only tested that the row was built. In the second tests I managed to implement the store of rows in a table. There is no interaction between rows and columns, yet. I could add tests for:

- Insert has less values than defined columns

- Insert has more values than defined columns

- Defined types in columns

- Autonumeric column

- Primary Key column

- Retrieve by primary key value

- Retrieve with given values (like MongoDB find), that is, query by example

- Query with operators

Those are things to write in the upcoming tests. I could record one or more videos, and then, I would switch to direct code in GitHub. The videos are for explaining the workflow, but after a few example I guess the process is clear. The idea is to implement using “baby steps”, and new tests/examples. TDD is like to play a videogame. Each new test/example is a challenge, and when we code to pass the test in green, we reach a new level in the game.

Keep tuned!

Angel “Java” Lopez

November 29, 2013

TDD Rocks! (4) SharpBase In C#

Filed under: C Sharp, Google, Open Source Projects, Test-Driven Development, Video — ajlopez @ 2:09 pm

Previous Post
Next Post

This is the second part in my series of using TDD in the writing of SharpBase, simple in-memory database, in C#. The new video:

As in the previous video, I’m adding tests, advancing by “baby steps”. The code is at:

I added tests over tables, testing how to add columns using their names. The columns still have no type or other features. In the next installment, I will add the insertion of a row to a table.

I hope you can understand my spoken Anglish ;-)

Keep tuned!

Angel “Java” Lopez

November 27, 2013

TDD Rocks! (3) SharpBase in C#

Filed under: C Sharp, Google, Open Source Projects, Test-Driven Development, Video — ajlopez @ 4:46 pm

Previous Post
Next Post

You already know, I like to code models in memory. Some time ago (months? years?) I started a project to build an in-memory relational database, using C#. To practice TDD, I decided to start it again, from scratch, documenting the first steps of the process in videos. After showing my workflow, the work will continue with commits in my GitHub Account. The first video:

The code is at:

Notice I didn’t make “big decisions” before the coding. I still don’t implement what is a Row, no idea yet for index and other stuff, like column types. I only coded the first use cases, with a simple API: create a database with name, check if it exists, etc…

I used the test library that comes with Visual Studio (Professional, Ultimate), already integrated in the IDE. Maybe, I could use NUnit or other solutions, but I’m proficient with this approach.

The important thing is not the tool: it is the workflow. Write a test with a new example, compile it, then code it to get green result, refactor, write a new example/test again, and so on. Don’t be afraid of refactoring (internal changes in implementation) or redesign (change in exposed API). And there are also test code refactoring. In general, in the refactoring we can add the patterns we know, cut repeated code, etc. In my case, I push for not have a lot of upfront design. That is the way I use in my personal and professional projects.

I hope you can understand spoken Anglish ;-) (Angel’s English)

Keep tuned!

Angel “Java” Lopez

Older Posts »

The Shocking Blue Green Theme Blog at


Get every new post delivered to your Inbox.

Join 56 other followers