I love Material Design

Good evening, fellow readers!

One thing you should know about me, is that I really enjoy working with pretty GUIs. Don't get me wrong, if the need arises, I can work on a rotten potato with a command line, but a properly designed user interface just makes me unreasonably happy.

Unfortunately, I did not like the recent developments in mobile design. Sorry, Apple, sorry, Microsoft, but your minimalistic flat interfaces just do not appeal to me. Google seemed to follow the same pattern for a while, but things changed in June when Material design was announced. The concept instantly caught my attention, but, as usual, I had to wait before I could use it with my own hand before I passed judgement.

And after several weeks of use, I must say that my expectations were met. Material-design apps seem to pop to life, and are all-around a pleasure to work with (developing them is a bit less pleasant, but more on that some other time).

The style seems to be catching on, too. Apart from the Google apps, I have already seen a file manager, a calculator and a task manager with Material, and there is a Linux distribution on it's way (check out Quantum OS, it looks fun).

Anyway, good job, Google designers! Keep up the good work!

Working with tables in Java

Good evening, fellow readers!

Today, I was working with some tables for my application, which reminded me how confusing they were when I started learning the language. Guides help, and so does the documentation at Oracle, but I would like to point out and explain some important aspects that were not clear for me personally.

My specific area of focus will be the implementation of tables in Swing. The first important thing to understand is that tables in Java were designed using the MVC (model-view-controller) pattern. The JTable class is responsible for the "view" part, and the TableModel class is responsible for the "model". "Control" is handled by various Listeners, but I won't be touching that now.

The only job of the JTable class is to display the table on the screen. The data to display, along with details of how it is obtained, sorted, and displayed, are handled by a TableModel associated with the JTable. It is possible to create simple tables without having to worry about a TableModel (or knowing that such a thing exists). When you create a new JTable, unless you specify a TableModel, an associated DefaultTableModel is automatically created.

If you have to display anything more than the most basic set of data, it is best to create your own model. This can be done by extending one of the two classes that implement the TableModel interface - AbstractTableModel or DefaultTableModel. The AbstractTableModel implements the majority of the methods defined in the TableModel interface and leaves three methods (getRowCount, getColumnCount, getValueAt) for the user to implement. It's the basis for any custom table model a programmer might create. The DefaultTableModel class is such an implementation. It is a subclass of the AbstractTableModel with the three methods implemented where the data is stored in a Vector of Vectors.

The decision between the two mostly comes down to the data. If you are OK with storing your data within the outdated Vector cl, using the DefaultTableModel is a lot less work. If you decide to build from the AbstractTableModel, you can choose to store the data however you want to but you'll need to implement the methods that allow the data to interact with the JTable seamlessly.

At the very least, you will have to implement the getRowCount, getColumnCount and getValueAt methods. As you may have guessed from the names, the getRowCount method should describe how to find out the number of rows in the table, the getColumnCount does the same for the number of columns, and the getValueAt is responsible for describing how the data is distributed among the cells. Here is a simple example of a custom AbstractTableModel:

import java.util.ArrayList;
import java.util.List;
import java.util.Locale;

public class EmployeeTable extends CustomTable {

private List dataList = new ArrayList();

        //declare the names of the column headers
private String columnNames[] = {"Name", "Phone"}; 



//in the constructor, retrieve an ArrayList of the data to be displayed
public EmployeeTable (){
super();
DatabaseReader readData = new DatabaseReader();
dataList = readData.read();
}

// the number of columns will be equal to the number of column headers we declared
@Override
public int getColumnCount(){
return columnNames.length;
}
  
        /*
         *to count the number of rows, we count the number of entries in the ArrayList.
         *The will be a row for each entry.
         */
@Override
public int getRowCount() {
return dataList.size();
}

        /*
         *This part is a bit tricky. When drawing the table, your JTable class will go through
         *each cell one by one. For each cell, this method will be called. We provide
         *instructions on how to get the data for the cell that is currently being drawn. First,
         *get the data from the current row, then get the data specific to the current column.
         */
@Override
public Object getValueAt(int row, int column) {
myData d =  dataList.get(row);
switch (column) {
            case 0:
                return d.getName();
            case 1:
                return d.getPhone();
        }
return new String();
}
}

My take on Abstract class vs Interface

Good evening, fellow readers!

Today I want to discuss a topic that is, apparently, an important one, when it comes to job interviews for junior developer positions. Specifically, the differences between an abstract class and an interface, and when one should be used over the other. Here goes.

An abstract class, in a nutshell, is a class, that has one or more abstract methods. A method is considered abstract if it has no implementations. For another class to inherit from an abstract class, it has to provide an implementation for those methods, or be considered abstract itself. For example, lets say you want to create a program, that draws shapes. You define a base abstract class:

public abstract class Shape {
    public abstract void draw(); // as this is an abstract method, the body is blank
    public int getColor() {
    //this is a concrete method, so it has a body
    }
}

And then you create some descendant classes:

public class Rectangle extends Shape {
    public void draw(){
    //this time, we will add code that does the actual drawing
    }
}

public class Circle extends Shape {
    public void draw(){
    //this time, we will add code that does the actual drawing
    }
}

As you can see, the draw() method is not implemented for the base class. This is because we do not know how to draw an undefined shape. A circle, or rectangle, on the other hand, are very specific shapes that have well-defined visual characteristics. The getColor() method can be used regardless of the actual shape, so we can provide an implementation in the base class.

The first way an abstract class is different from an interface is that an interface is not a class. It is basically just a collection of abstract methods. Any class that implements an interface must implement all of the method headings listed in the interface definition. There can be no method implementations inside the interface itself.

I find that a good way to look at the two is a "is-a" vs "has-a/can-do-this" type of relationship. For example, a cottage is a house, and it has an air-conditioning system. You could have an abstract class House, an AirConditioning interface, and a Cottage class that extends House and implements AirConditioning. So, one reason to use an interface over an abstract class is when there is no strong logical relationship between objects. A Car class might also need to implement an AirConditioning interface, but is is obviously not a House. Strictly speaking, relationships within the code, that make sense from a common point of view, are not required, but greatly improve code readibility, and, as a result, make it easier to maintain.

A second reason to use interfaces is the fact that Java does not support multiple inheritance, and interfaces provide a type of work-around (a class can extend only one class, but can implement any number of interfaces).

The last important difference is that an abstract class, unlike an interface, can have methods with actual implementation details, so shared methods can be placed right in the base class. This is especially important when the application design is constantly developing - if you add new method headings to an interface, then all of the classes that already implement that interface will have to be changed to implement the new methods, which can be quite a pain. With abstract classes, it is likely that you can just add the method to the abstract class.

Anyway, this covers the most important differences. The concept was a bit baffling for me for a while, so I hope this article helps people get a better understanding.

My new unemployed life, and my first commercial project

Good evening, fellow readers!

I guess you could say that today was a rather important day. First of all, it was the first weekday of my newfound unemployment. I can already say that I am not likely to enjoy this lifestyle in the long run. I enjoy human contact at the workplace (more often than not), there are plenty of distractions at home (I'm looking at you, League of Legends) and naps are always tempting. I also need a new chair. In general, I certainly hope I will be able to find a job soon. Which brings me to the second important event of the day.

Today, I started working on my first commercial Java project. Yay!

I began work on an empoyee certification management system for a company that is somehow connected to aviation. I called my application "Certification manager 2014". Creative, I know.

 In short, the software will have to:

• store information about the employees of the company and the various certificates each of them has
• keep track of the certificate expiration dates and warn the user when some certificate is about to expire
• create a schedule for employee training 
• generate analytical reports for all of the above.

So, the task is quite simple. It is made a bit harder by the fact that the client requested the data to be saved in an MS Access database, but I don't think that will be much of a problem.

The client requested an interface prototype by Tuesday night. I finished it within a couple of hours. Here is what I got:

Unfortunately, I did not find anything challenging in today's task. Java's Swing used to give me some trouble a while ago, but it became a lot more manageable once I finished a couple of projects with it. MiG Layout is a must, though - check it out if you plan on making desktop apps.

I had some fun picking out the icons from a free repository. There's just something about this strict look/feel that caught my eye.

Overall, after working exclusively on software for my own personal use, I find it quite exciting to write something that will be used by a real actual organisation. I will submit the first results tomorrow. Hope the client is satisfied)

Hello!

Good evening, future readers!

My name is Anton Medviediev. I am a 24-year-old guy from Kiev, Ukraine. For the past four years, I had a decent, well-paid job in management for a small international company. And yesterday, I quit. Why? Well, software development, of course.

I've been passionate about everything computer-related since I was a child. When I was 12, I started dabbling in programming. Back then, the only computer in our house was a 10-year-old laptop with a 33 MHz processor and 4 megabytes of RAM, which was pitiful even in 2002. The best games I could run were also about as old as I was, so my brewing gaming addiction was left largely unsatisfied. The best solution I could come up with at the time was to start writing my own games. I went to my local library, got a book on QBasic (oh, how I wish it was C++), and opened up the IDE as soon as I got home. And so it began.

By the time I was 16, I had 5 or 6 finished primitive games for DOS. In retrospect, it would have made sense to continue my education in computer sciences, but, for a number of reasons, I ended up getting a Master's in management of international business, and found a job in the field. Programming was abandoned for quite a while.

However, my job did not make me happy. I kept reading blogs, articles and books on IT instead of stuff that would help me with my career. A year and a half ago, I randomly started learning Java and I loved it. I coded after work and I coded on the weekends, but I found it difficult to do so effectively after intense 8-, 9-, 10-hour workdays, so my progress was not great. What was great, however, was the fact that I realized that a career in software development was the thing I wanted all along.

I saved up some money and quit. Starting today, I can focus on perfecting my programming skills and getting a job in the field. My progress will be documented here.

What to expect from this blog:

• Information and updates on the progress of my current programming projects
• Problems I encounter and how I solve them (or don't)
• Book reviews and useful articles
• My thoughts about tools and technologies I use (or don't)
• Stories about any job interviews I get invited to

What not to expect:

• Guides (I'm pretty sure I am not yet qualified to give such advice to anyone)

So, welcome, and enjoy! :)