Fortsätt till huvudinnehåll

Inlägg

Test Driven Development of JavaFX

I just completed the  code.makery javafx-8 tutorial  by Marco Jacob. It took a couple of hours to complete and there is quite a lot of implementation done ahead of it being needed which make it a bit hard to follow. But overall I recommend it to get a good understanding how the different MVC parts in a JavaFX project interacts. Now, is it possible to use a TDD approach when developing a JavaFX application? Seaching the net a bit I found  this  presentation by Hendrik Ebbers that points to  TestFX . A test framework that provides "simple and clean testing for JavaFX". I am adding TestFX to the list of tools to be used during the development of my Record Collector Java mini project.

GUI prototyping with Scene Builder

Back in the days when I used to code HTML (for fun) I stayed away from WYSIWYG tools like FrontPage and Dreamweaver. When it comes to GUIs however I think it can be helpful to use a graphical layout tool. At least for prototyping. Today I did some prototyping with Scene Builder  in order to create a GUI for The Record Collector application. My impression so far is that it is easy to work with and speeds up the layout work a lot. Now let's see if I can turn The Record Collector to a good Model View Controller (MVC) project.

Swing on over to Java FX

Creating GUIs is something I do quite rarely. Hence when I started thinking about the GUI for the Record Collector application I opened up my old Java book and started reading about Swing. Today however I was informed that Java FX is preferred over Swing. Ok, then let's  Swing on over to Java FX .

TheRecordCollector is live on GitHub

The first commit for my new mini project has been pushed to GitHub. It can be found at:  https://github.com/Backhage/TheRecordCollector So far it doesn't contain much but I will be pushing as soon as I have something new. The "customers" will be my father and my uncle so I plan to demo something simple, but functional, to them as soon as possible.

New Java mini project

Today I started a new Java mini project. This one will be a bit bigger than usual. The target is to create an application for keeping a database of vinyl records. My father and uncle are both record collectors and are lacking an easy desktop application for keeping a record of their vinyls. During the development of this application I am planning to: Use IntelliJ  as IDE instead of Eclipse  that I normally use. Use Git  for version control. Add the project to  GitHub . Use  Mockito  for mocking the Data Access Object (DAO) when testing. Create a MySQL  database that is stored on a remote server and can be accessed over the net. Create a GUI for the application. So far I have installed IntelliJ and MySql locally. Set up a database and tried out some queries to see that it works. Also prototyped some SQL requests in Java.  One thing I realized that I really need to consider is how to handle exceptions due to database access issues. A...

Back to the world of functional programming

After some mini projects in Java (requesting bus departures using the local bus company's REST API and trying some fork/join optimizations) I returned to the functional programming course today. I must say that higher order functions ,  anonymous functions , and  traits  makes my head spin. Doing the exercises is quite challenging, but really fun! One thing that bugs me a bit though is thet  sbt  takes a bit too long to compile and run the tests ( real 0m8.395s ) which makes the design loop a bit longer than I would like. Remember that this is a really small project that only includes a couple of source files and no I/O. Compile and run the tests should take less than a second. I wonder how sbt scales. Anyway, great approach by Martin Odersky to advocate a test driven approach to the excersises!

The importance of good preparation work

This weekend I have been working on our staircase at home. The previous owners re-painted the staircase before they moved out. Unfortunately they "forgot" to do the preparation work properly so now the paint is flaking and looks terrible. Just as important as preparing before you paint is preparing your software before adding new functionality to it. When you are planning to add a new feature take a moment and ask yourself if your code is ready for it. The first coding task should be to ensure the new functionality fits well into the structure of the part of the code that is affected. There is a big possibility that some restructuring of the code is needed before it can be extended in a good way. Doing this will help you keep the code in a good condition. You don't want code that looks terrible and needs to be stripped down completely and "repainted, do you?