Enter the OSGi – Cool shit is on the way

holistic-net has a bunch of little projects/products, all of which has something to do with IBM Connections – a sort of business social website for either intra- or internet.  Greenhouse is a good example of it.  In order to bunch our products and services which do something with Connections, we are looking into transferring those products/projects into a completely modular java project.  The framework of choice — Eclipse 4.

I am new to eclipse and OSGi development, even though I started to dabble in extending the XPage runtime with OSGi, I am not ashamed to admit that I was not sure what I was doing… Those of you on stack overflow more than likely know that I have asked many questions regarding OSGi dev and I have not been overly successful.  I am ashamed to admit that I did not first look into how eclipse development really works and decided instead to jump off the deep end and somehow expect it all to work.  Lesson learned.

Come to think of it, I learned a great deal in the past two weeks.  So much so that I am about to burst.  Moreover, today is one of those days that shows why I want to be a programmer, why I love my job, and why I cannot imagine doing anything else.  In the past two weeks I was frustrated with example projects, fearful that I will not be able to learn the concepts and get things going, and perhaps a bit down on myself.  Today was the pivotal moment when it all went click and I can say that I am not only happy with what I have accomplished, but I am also seeing the full power of the eclipse framework.  Even more than that, I think I can take what I learned with plug in management and organization and move it into all of my future project development.  (Although that is more than likely just personal preference stuff anyway)

Ok, so none of this is making much sense to “normal” people so I guess I better explain myself.

1. Separation of UI development and data management.
What I mean by this is that all you need is a data model.  This model is best in an Interface.  Aside from this, you can have a service model interface.  These two interfaces are then used to build the UI.  Actually, what I have been doing is using the model interface to build a jface bean.  There seems to be a bit more to it than building a Bean for XPages, but not too much more.  In fact, it is pretty easy when it comes down to it.  Just build an abstract bean model and then just extend it and add a bit more code into your setX methods.  This allows the GUI to not care at all where and how it is getting its data.  It only wants it to follow the interface that is located in the model plug-in.  This allows for easier GUI testing, and the gui does not have to be updated if the Data Services change.

2. Modular Design
Imagine you have two brothers.  Both of them are going to use the same budgeting software programs that you design.  Brother one, lets call David, is not too bad with computers, has no fear of it, and can follow your install directions, even if they are a bit more complex.  For him, you want to use your default design of saving information into a database.  This is the easiest way to keep track of and query your data, so why not.  You can deliver the project easily to him with the data service plug-ins necessary for JPA data persistence.  And since your data is saved in a model, you can use the service Interface to verify that you are delivering the proper functions.  Now let’s say you have a second brother named Brian.  We can admit that he is a bit of a douche and does not like fancy stuff.  He likes his toys to be slow and if he can make you run around the block a few times, he will gladly go inside, get a lawn chair and a lemonade, and he will watch you jump through hoops on that blistery summer afternoon.  You can build another service that follows the model service interface and it will handle the data the way Brian needs.  Later, when John comes along, he can decide if he wants to be a Brian or a David, you still have both service implementations and he can decide which he wants to use.

We can even take this a step further and not limit it to our annoying brothers.  We can also look at pure content.  We have an application and we want to define different roles to it.  The first role is purely user input and basic displays.  He can have an instance installed onto his computer containing the plug-ins that allow him to most efficiently perform his task.  The second role is more of an administrator.  He needs to be able to do everything that first role can do, plus this user needs to be able to perform administrative tasks and needs advanced perspectives to handle those tasks.  His instance of the application will include those plug-ins all of which extend the base UI.

3. Styling controlled through CSS
Actually, I am not sure whether or not this was an option in normal SWING UI development.  I do not think so.  Anyway it makes customizing the front end very easy.  I do not know too much about this yet, but I see it as a cool ability.

4. Event Driven application with contexts and a lot of cool shit like injection
The framework takes care of all of your application needs.  Set an object into the context and be done with it.  If the object is configured to be available, the framework will also inject it into your methods and you do not have to worry much.  (You need to be smart, but still)  This eliminates the need for a single factory class or program class that maintains critical program data. There is so much candy that I would have to write a book to get into it all.  I suggest you try it yourself.

 

This means that cool stuff is going to be done with BudgIt, or well MoneySucks as I have now started to call it.  I will be transferring everything into an Eclipse 4 application.  I am excited and cannot wait to get started.  Come to think of it, I might as well start downloading eclipse right now!

May BudgIt RIP

Death

It was a good project.

It was a project that taught me a lot.

I had hoped it would bring me financial security.

Instead it bit the dirt.


Alright, that is a bit harsh.  It is true that BudgIt was a project that I continuously worked on throughout my apprenticeship.  In all honesty, it was something that I have been very proud of, but over the years, when I learned something new, or wanted to learn something new, I would build it into BudgIt.  In the end, it was too big, too bloated, and has too many errors that were caused by inexperience and just not knowing what APIs and possibilities were open to the programmer.  I was able to learn swing — actually I have BudgIt to thank for my entire knowledge of OOP and Java — I learned SQL, relational database theory, I learned about JDBCs, and well, everything not IBM Notes related was learned by working on BudgIt, including working with eclipse and repositories.  I worked on it partially at work, during vacation, weekends, private time….

With a particular sadness, I now officially declare BudgIt dead.

Why you may ask?

1. All SQL code was written out in a single class.  In the end, that single class was a monstrosity including thousands of lines of code that was not maintainable.  I did not use any sort of design pattern to abstract the SQL data from the classes.

2. In an attempt to keep the SQL database information secure, I built in too much junk to maintain passwords and encrypt stuff… can you say bloated?

3. Too many dependencies.  Change one thing, the rest falls apart.

4. Really bad GUI design. — I mean terrible.  When I see what front ends are being used in modern software, this front end reminded me of pictures of Notes applications I saw from the 90s.  It is not that Swing cannot be used to make great front ends, I am terrible at making front ends!

5. This above all, it is dead because I get a stomach ache when I see this thing and think about fixing it and the complete redo that it needs to work.


Rebirth

Fear not! For even I will not keep track of my budget using excel for long **pukes a little at the thought**, but I have started a new project that will incorporate a few of the features of BudgIt, reuse some code, and be a cleaner OPEN SOURCE implementation!  That is right, OPEN SOURCE! Dont believe me? Take a look at the GitHub repository!  I like to keep my code local as much as possible because there is an inward irrational fear of someone critiquing my code too much, so I like to post it when I think that it is worthy of peer review, but in this case I will commit when I want to continue working on it with a different computer.  The concept of this new project will be almost the same as BudgIt, but with a few differences.

1. I am new to JPA, but from what I read about it, it is an awesome way to store objects into a database and recall them later.  I will be using JPA instead of manually written SQL.  My only open question at the moment is whether or not I have to build a custom server/client model to get it all to work.

2. Each user can have their own database, why the heck should I use one database for all potential users on a system.  Besides, most users have their own computer nowadays anyway.  I know that windows users have their own protected library/user directory, linux has the same, and since Mac is based on linux, there should not be too big a difference.

3. I want the classes built in such a way that I can change a class without destroying others.  (Kill all beginner errors)

4. This is an open point for me, but I think I am going to ask for help designing the front end.  I have no problems coding it, but I lack what some might call … artistic talent

5. I have learned a few things maintaining my budget with excel and figured out what I want to see at start up, and what I do not need to see and can call up extra.  I want to build this into the program.

I might rename this to MoneySucks, but I might also keep the name BudgIt because it is a pretty cool name.  I would just have to dub it version 3.

Java and Encryption

Welcome to a small tutorial like lesson where I go into a bit of encryption etc in Java.  This will not be a highly detailed discuss, I will just go into the basics.

First off, what is encryption?
Cryptography is, in its most basic form, preparing information for transmission in such a way that it cannot be read or understood by others.  Cryptography got its start thousands of years ago, and has taken on may forms.  My favorite historical example is a method whereby a piece of “paper” could be wrapped around a stick.  The message would then be written on the paper.  Once unwrapped, it would be difficult to know what it was saying without knowing the diameter of the stick that was used to “encrypt” the message, if you could tell what it was in the first place.  It is said that the Spartans used this system.  Later, another encryption system was used where the letters would be transposed a few spaces.  In other words, ‘A’ would become ‘C’, ‘B’ to ‘D’ and so on.  Current methods are not too different.

Why am I using encryption in BudgIt?

My use case is fairly simple.  I want to be able to store some basic program information that the normal user should not be able to see or change without my business logic.  I need the information available without a database connection, so that would not do, and although I could use some sort of a binary reader/writer, the point of BudgIt is to learn, so that is what I am going to do.

Encryption would probably be better if the goal is to transfer data across the internet.  This would hopefully prevent eavesdroppers from getting personal and sensitive information. although you still have to worry about the NSA.  😀  In fact, it has even been reported that they have overseen the development of a few ciphers in order to make sure that they have a “master key” that can unlock any encrypted transmission.  But alas: politics is not the reason for this post, so lets just jump into it.

Lets create a key in java

private void createKey(){
		String msg;
		KeyGenerator keygenerator;
		SecretKey key;
		String keyfile = FILE_KEY;
		ObjectOutputStream oos = null;
		File f = new File(keyfile);
		if(f.exists()){
			//Warning: Key already exists!  Would you like to generate a new key?  This could make information that already exists unreadable.;

		}
		try{
			keygenerator = KeyGenerator.getInstance("DES"); // this says to use the DES algorithm when it creates the key file.
			keygenerator.init(new SecureRandom());
			key = keygenerator.generateKey();
//initiate the key generator and create a key
			SecretKeyFactory skf = SecretKeyFactory.getInstance("DES");
			Class<?> spec = Class.forName("javax.crypto.spec.DESKeySpec");
			DESKeySpec ks = (DESKeySpec) skf.getKeySpec(key,  spec);

			oos = new ObjectOutputStream(new FileOutputStream(keyfile));
			oos.writeObject(ks.getKey());

			Cipher c = Cipher.getInstance("DES/CFB8/NoPadding");
			c.init(Cipher.ENCRYPT_MODE, key);
			oos.writeObject(c.getIV());
			oos.close();

		} catch(NoSuchAlgorithmException e) + many others that I will skip{
			//The encryption algorithm DES is unknown to this system.
		} finally{
			if (oos != null){
				try {
					oos.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
			}
		}
	}

This is a very complex bit of code to wade through and I do not really want to rip it to pieces explaining what each part does, but I will say this.  This bit of code is creating a key and saving that key to a file to be used later by an encryption and decryption function.  It is important to note that if this key is lost, the files saved using this key will no longer be able to be read.  (unless you are the NSA).

 

Next, we are going to use that file to encrypt an array of strings.  Again, I am not going to go line by line through it, but it is pretty self explanatory.  It looks more scary than it really is.

public void encryptToFile(String fileName, String[] strings) {

		// check existance of the key
		File f = new File(FILE_KEY);
		if (!f.exists()){
			//An encryption key could not be found!  
		}

		ObjectInputStream ois = null;
		PrintWriter pw = null;

		try{
			ois = new ObjectInputStream(new FileInputStream(f));
			DESKeySpec ks = new DESKeySpec((byte[])ois.readObject());
			SecretKeyFactory skf = SecretKeyFactory.getInstance("DES");
			SecretKey key = skf.generateSecret(ks);

			Cipher c = Cipher.getInstance("DES/CFB8/NoPadding");
			c.init(Cipher.ENCRYPT_MODE, key, new IvParameterSpec((byte[])ois.readObject()));
			CipherOutputStream cos = new CipherOutputStream(new FileOutputStream(fileName), c);
			pw = new PrintWriter(new OutputStreamWriter(cos));
			for (String s : strings){
				pw.println(s);
			}
			pw.flush();
		} catch long list of exceptions {

		} finally{
			if(ois != null){
				try {
					ois.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
			}
			if (pw != null){
				pw.close();
			}
		}
	}

Here we are decrypting a file that we already saved.  This must use the same key that we used to encrypt the file.

 
public ArrayList<String> dycryptFile(String fileName) throws FileNotFoundException, IOException{

		ArrayList strings = new ArrayList();

		String msg;
		// check existance of the key
		File f = new File(FILE_KEY);
		if (!f.exists()){
			//An encryption key could not be found!
		}

		ObjectInputStream ois = null;
		CipherInputStream cis = null;
		BufferedReader br = null;
		String input = "";

		try{
			//********************************************** get cipher**********************************
			ois = new ObjectInputStream(new FileInputStream(f));
			DESKeySpec ks = new DESKeySpec((byte[])ois.readObject());
			SecretKeyFactory skf = SecretKeyFactory.getInstance("DES");
			SecretKey key = skf.generateSecret(ks);

			Cipher c = Cipher.getInstance("DES/CFB8/NoPadding");
			c.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec((byte[])ois.readObject()));
			// ************************************************* decrypt file********************************

			cis = new CipherInputStream(new FileInputStream(fileName), c);
			br = new BufferedReader( new InputStreamReader(cis));

			while ((input = br.readLine()) != null){
				strings.add(input);
			}

		} 
		//... catch long list of exceptions ...

		} finally {
			if(ois != null){
				try {
					ois.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
			}
			if(br != null){
				br.close();
			}
		}
		return strings;
	}

This is just a quick block to get all of you interested people an example to look at.  I do hope to write again soon and go into each of the methods and say what each part is actually doing and why it is important, but for now I hope that it can be understood.