About reederProgramming

I already have an about me page, so I will just put a quick bit of info here. I am a Notes/Domino developer at holistic-net GmbH located in Hannover, Germany. I use Java primarily at home and as often as I can at work. I have dabbled in C# and a few other languages and platforms. This website started out as a place for me to quickly store and access some of my most important how-tos and has started to become a place where I can really help others too!

A few Years of XPage Developement – Part 3

Recovery

Enter Domino version 9.0.x and goodbye to the “Lotus”

The first thing I heard about the newest version of Domino was that the term “Lotus” was banned.  The second was regarding the debugging functionality.  Since that was my single most influential headache, I decided that I would do a bit of testing and build a Demonstration database for the 2013 Connect Comes 2U hosted by holistic-net in Hannover and SOFTWERK in Fürth.  The demonstration was primarily a padawan level database written by a Jedi Knight level developer.  Key controls were implemented with default values and simple data binding.  Using the Application Layout and the OneUI themes, a front end was created very quickly.  Because limited JavaScript code was used, the debugger was not an issue at that point, though I did make limited use of it.  The most awesome point about this particular demonstration database was that CRUD operations were performed on data stored in a MySQL database.  Even though the database design was relatively simple, the GUI design itself was impressive and took an unbelievable 2 weeks to implement.

With a few words of praise from the boss, the wonder of a new Domino version that showed great potential, and the desire to graduate to “Jedi Master” status, I took on another project and entered Tier 3.   Tier 3 is marked by excessive use of Java Code and a limited use of JavaScript.  The debate between which is best has been touched upon by many a blogger, and so I am not going to get into that at all, but I will say that the IDE, based on eclipse, is very java ready.  Most of the problems I had with JavaScript were no longer an issue when implemented in Java.  The ‘if’ statement issue, explained under Solar, is caught by the java compiler as are many other similar errors.  If you state that a variable is of type “Document” it can never be set accidently to a “DocumentCollection” value and so on.  This is my primary reasoning behind standing behind java implementation of XPage functionality as opposed to JavaScript.

Once it became clear that I would be given a second Customer XPage project, I started to dive into the Java Code and create my own utility classes.  This single preparation project led to another and both of them were used for the customer project.  The first of these has been titled “holisticXutils” or “hxu”.  hxu is primarily a java jar containing Java helper classes.  It provides shortcuts for working with vectors, strings, and Notes Names.  It provides functionality to help with document locking, logging, development, and property files.  It contains custom controls that help with Scrollable Panels, code logging directly visible on the browser to those with the correct ACL role, and a few JavaScript helpers as well.

A few big strides were taken in this Project.  Most notable, all JavaScript is written in an Object Oriented Style.  One big issue that is currently seen while supporting the Solar project is that all JavaScript functions are written in one massive SSJS library file.  All code is written directly after another.  Adding to the fact that these functions are not listed alphabetically, it takes forever to find what you need if you are unsure how the function was named and cannot use the ‘find’ function.  Writing all code in an object oriented style allows for an application that is, simply put, maintainable, even if it does introduce some problems of its own, i.e. nested function calls are not listed on the left side panel.

Version 0 of hxu was primarily testing and getting comfortable with the IBM Domino API.  This is not easily done for someone who only ever coded in LotusScript.  If you type in “View” in the IDE, you get a View object in many different packages.  It took me a while to figure out that the correct one is in the lotus.domino package.  Getting a handle on the session was also not very intuitive, but simple now that I did it almost a thousand times or more.  Version 1 was the first version used in an actual project.  It did not assume that the extension libraries were installed, but it did require OpenLog from Paul Withers.  (Available on openNTF).  Thanks Mr. Withers!  Version 2.x expanded the Logging functionality and required an update to the databases that implemented version 1.x.  It included Logging into my second preparation Project, holistic XLogger, or “Xlogger”, or “hxl”.  We will have to get into version 3 in a moment.

One huge problem that I had was logging.  I successfully used openLog and the tools provided by Mr Withers to track uncaught errors, but this functionality did not go deep enough for me.  I wanted    the ability to document each user’s session.  I wanted to know what browser he used, which version, and a list of all things done so that I can easily diagnose any problem that arose during productive use of an application I create.  Logging things to the Server log is a questionable practice at best, and an absolute no-go at worst.  I had already implemented all of this in my debugging custom control; all I needed was a way to expand this functionality to save information programmatically to a single document created for the user’s session.  With a quick update to hxu, it was possible to create a single logging function that saved data in multiple places at one time.  These places can also be configured using designer in the appropriate .properties file.

After these two preparation projects – hxu and hxl, I felt confident in my ability as a Jedy Master level XPage developer.  I had all the tools I needed to be successful.  Logging, Java, JavaScript, Extension Libraries, I was a dog on the track waiting for the gates to open and a final “do it” from men in charge.  The Customer Project River was given a go and off I went.

A few Years of XPage Developement – Part 2

Solar – Customer Project 1

Customer project 1, nicknamed Solar, was a solid tier 2 project.  We can refer to tier 2 as “Jedi Knight” level.  As a “Jedi Knight”, the programmer will use not only controls, but will also write some JavaScript code.

Solar was a very large project.  It was to serve as a single entry point for many other databases which all used the same design template.  Beware of the false sense of implied simplicity one could extrapolate from the phrase “same design template”.  Due to the configurable nature of the source databases, the individual source databases were as different from each other as the planets in the solar system, hence the project name.  Style sheets and a bit of JavaScript can change the style class name of a control, but this was configurability to an extreme. It included views created by script, language configuration, keyword configuration, configurations for configurations, too many for a Jedi Knight developer.  But let’s dive into the problems, take a look at what tools were available, and the details of the Solar experience.

Solar was built on Domino 8.5.3 and an appropriate version of the Extension Libraries.  The Extension Library was available for a little while, yet still in its infancy.  Many controls either did not work properly, and some did not work at all.  As is seen even today, if you want to build an application using XPages without the Extension Libraries, most of the controls and functionality that a customer and end user take for granted are not available.  Dialogs that are not self-implemented are not available; there are no value picker dialogs, no name pickers, or “advanced” controls.  Every view shown in an XPage basically needs to be constructed in the XPage using the View Panel or DataTable controls, and in many cases, those XPages must be updated if the background view changes.  There is no “one size fits all” approach.  XPage development without the Extension libraries?!?  NO THANK YOU!

Besides the ever present absence of what Classic Notes developers will call “standard controls” in the IBM installation, there were many other hurdles to overcome.  The most hindering of them was lack of developer help material.  Everyone was new to XPages and a good centralized help center did not exist.  The Designer help was no help at all, pun intended, and there was no home forum for designers.  Of course there were websites out there that to this day offer a place for people to ask questions and get help if they need it; however, unlike the current StackOverflow forums, you were lucky if your question ever received an answer and if it did, it almost never helped.  Being the first of the company to take the plunge into XPages, there was no person locally who could take a look at code and tell me what I was doing wrong.  Partner companies rarely had it better.  The developer was on his own in the early day of XPages.  There was no Designer based Help application, no good forums, no fellow developers, no real documentation of the basic IBM libraries or the extension libraries, and very little more than demonstration databases provided by IBM (Team Room template) and openNTF (numerous applications delivered with the ExtLibs).  The problems of figuring out what to use and when to use them were only the tip of the problems back then.

The more interesting problems happened when you did not know what the problem was, only the symptom.  This is a problem that exists to a point even today, but not nearly as bad.  Domino 8.5 did not come with a debugging option for JavaScript.  This was a nightmare and a big reason why I refuse to develop XPage applications for any server below Domino 9.  I will not do it.  (Truth be told, if the boss says do it, you do it….)  Not having a debugger is one issue in and of itself, but it is made much worse with the implementation of the JavaScript coding windows of the IDE.  When you write JavaScript code in designer, it is only slightly better than writing the code in notepad.  Certain errors could and should be found.  For this, let’s look at an example.  If you want to test that apple equals oranges then do something with pears, the code should look like this:

if (apples == oranges){  pears.doSomething();}

but you write:

if(apples = oranges){ pears.doSomething();}

a very strange thing happens.  First off, this error WILL NEVER BE FOUND AUTOMATICALLY. It will not be spit out as an error during run time, or at design time.  It will simply and quietly replace the value of apples with the value of oranges.  This sort of mistake, which can happen unbelievably quickly when trying to type functions in a semi quick way, can cost hours if not days of searching when you do not know that it happened and can just see that the result of the function is wrong, if you notice in the first place.  Without debugging functionality, you can kiss your week goodbye.  The only option you really have is to spit out values to the server console and hope you eventually find it, or have a bunch of interns read your pages and pages of code to see if they find anything.

If that was not enough, when you create a SSJS library, all un-nested functions and variables are written on the left side panel.  This is the same functionality as seen when writing a Lotusscript library and is nothing new.  One huge disadvantage is that these variables are not sorted alphabetically, but rather in the order in which they are in the file.  This is highly annoying.  During development, the developer must write the code in alphabetical order or risk not finding the functions later.

Because of these limitation, the Solar project ended up taking roughly four times longer than planned, and even was in danger of reaching or exceeding a year of development time.  At that point, I did not want to touch another XPage project as long as I lived.  I was frustrated, angry, and dumbfounded.  IBM had sold something as “easy” and “quick” and “the future” and all I wanted to do was bury it outside next to Spot the cat.  We had seen that it was not easy, it was not quick, it was expensive for the customer, and if it was to have any future at all, things would have to change dramatically in the next version of Domino.

A few Years of XPage Developement – Part 1

Introduction

A few weeks ago, I was given the task of writing a blog entry for holistic thinking about my/our XPages experiences over the past few years.  It was thought that this entry would be, perhaps, a page or two in word and that would be it.  Boy was I wrong.  It just so happens that there is just a ton of stuff to write, a lot of ideas to get across, and, for that reason, I am separating this into a few different entries.  In this series we are going to be discussing how my XPage experiences have changed over the course of the past four years and how I expect them to continue to change.  We will be discussing two major customer projects (no worries, it is all anonymized), the XPage learning curve, and the major tiers of XPage developers.  We will look into the problems that we came across, my reactions to them, and how they were solved, or not.

The early years

I had my first taste of XPages in 2011 working as an apprentice at holistic-net.  Enthusiastically, I built my very first web application which was designed to maintain my daily records for the IHK (Industrie- und Handelskammer).  I had already built numerous Classic Notes applications by that point including a Lotus Notes Client version of that same application.  I was pretty satisfied with how quickly I could pick up Lotusscript, the design patterns, and all of the other stuff one needs to be successful with Lotus.  As one old commercial stated, if you can work with spreadsheets, you can build a Lotus Notes application.   This started to be the case with XPages as well.  After all, putting some controls on a page and binding them to a background document or view is not that hard, right?  RIGHT!  Well, almost. Let’s break down XPage development into five different tiers, expanding on a blog entry done by Niklas Heidloff where he described 3 classifications of XPage developers.  A tier 1 developer, affectionately referred to as the “Padawan”, will take a few controls and throw them onto the XPage and call it a day.  My Records Application was little more than this.  It had simple data bindings and was not much work.  It was simply reusing existing controls in their most basic form.  Nothing from it could be reused in other XPages, almost no JavaScript was used if any at al, and absolutely no Java was written either.  The only good thing about this project was that I was able to get accustomed to the standard IBM controls.  I guess every developer is going to have to have such a project where they just get used to standard controls and try to do something with them.  This particular application was used for a grand total of 2 weeks before going back to classic notes and was an absolute failure.  It did however form the foundation for Customer Project 1.

Beginning with Java

Welcome to the Java Tutorial

Welcome to a new tutorial of learning how to program with java!  I have tried to make videos of myself doing all of this, but I think this will work out better.  It is my goal in this tutorial to teach anyone interested the basics of programming.  We could start in any language, but I feel that Java offers the best structure to learn Object Oriented Programming.

Object Oriented Programming (OOP) is a way to organize a program into objects.  Java makes OOP a founding philosophy that creates a language that is very robust and expandable while making a complex program easy(er) to understand.  Granted it could be said that java just makes simple tasks very complex and that would not be wrong.  But it is also a very large leap forward from C++.

Java is a very interesting language.  A few advantages are:

  • forced Exception (error) Handling.  Any error that is created and known about must be handled at design time or else the program will not “compile”
  • Strict OOP programming style
  • platform and operating system independance
  • well documented
  • plenty of online tutorials
  • free Integrated Development Environments (IDEs)
  • easy switch to other OOP languages such as Microsoft’s C#

Numerous programs have been created with Java, including games. Minecraft is one example, but there are plenty more such as Applets that run on browsers that aide in seat selection at an online ticketing service, programs that automate coffee machines, parking machines, and plenty of others.  There is no better language to start with, not even, in my opinion, Visual Basic.

Let’s set up our environment!

In order to start our programming tutorial, a few programs must be in place.  The first step is to get the Java Runtime Environment (JRE).  In many cases, this is already installed.  The easiest way to verify this is to open a command line window and give the java -version command

java -version command

java -version command

If the screen looks like the window above, regardless of which java version is displayed, than a JRE is already installed and you need not worry about downloading it.  Otherwise, it must be installed.  To do this, go to the following webpage and search for the appropriate JRE install file:
http://www.java.com/en/download/index.jsp
It is also easy to find by putting JRE Download into google.

The next step would be to download the java development tookit (JDK).  That can be done at the following website
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Again, only a simple google search is needed.  All you need is the standard edition.  It is not necessary to sign up or register for any of these downloads.

The third download is also very easy to find, and it will not be “installed” into the system, just started.  For this tutorial series, we will be using eclipse Juno.  Currently the newest release is Eclipse Kepler, but the two are almost identical and it is not important to have the same version as I have.  You can download eclipse from here:
http://www.eclipse.org/downloads/
I often download the EE version, but the standard is just as well for getting into java for the first time and for mostly all projects.  Once this file downloads, extract it into a place that it can stay for a longer period of time.  I do not recommend the desktop, but that is your decision.

Once that is finished, we will want to start eclipse.  To do that, just open that folder and open the eclipse executable that has a purple icon:
EclipseFolderA window will open up where you can select your desired workspace.  The default will be located in your personal documents folder.  You can change this if desired, or even create a new folder easily.  I started out creating a new workspace for every program I worked on, but this is unnecessary.
eclipseWorkspaceWith these steps done, eclipse will start and it is possible to start programming.  In the next tutorial, we will look at where to go from here, including looking at a few basic types in Java, and creating a program that allows us to put information into the user console.

 

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.




WPF is really awesome!

Today, I had the great experiance of leaving the office with a feeling of, “Oh my God, IT WORKS”!

First of all, dealing with a graphical user interface in Java can be a pain in the butt.  Let me first write up an example in code:

JFrame f = new JFrame()  //This is my window that I want to place everything in.
f.setBackgroundColor(Color.Blue); //This should work, right?  wrong!!!  

Even though the JFrame has a background color property and you think you should be able to do it this way, you actually cannot set the background color of the window in this way.  The proper code would be:

JFrame f = new JFrame();
f.getContentPane().setBackgroundColor(Color.Blue);

It is first necessary to get the pane where the content is going first before you can set the background property.  To the newbie in Swing, this is a nightmare.  You set a property that you think should have the desired effect, but you end up wasting a great deal of time searching for the correct object to set one specific property that you think should go quickly.  This is often not taken into account when coming up with time tables and figuring out how long a certain project should take to develop.  Of course if the developer is experienced and knows all of these crazy things, or of the newbie programmer has the best book on Java Swing (THANKS MOM!!!!) currently available, then that time can also be minimal.

My experience in WPF today was extremely favorable.  First off, I did not have 1 issue setting a property.  If the specific property was available to me, it did something when I changed it.  It may not have done what I thought it did, and I may have had to change a different property in another object, but it still did something.  I did not have to wonder what I did wrong, and in many cases the error messages that I got where enough to send me in the correct direction.  This above any other point leads me to the conclusion that I have been working with the wrong GUI for the past three years.  And if the GUI was wrong, then I am wondering if I am using the correct language.  For as much as C# can be confusing and not very intuitive, and for as much as I may not like having to look up the correct DLL file to import in order to reference the class I want, I must say that this alone is a reason to make a fundamental switch in regards to my preferred programming language.  One last thing I have to say, is that the GUI looks GREAT and I am horrible at front end design.  I mean horrible!

My goal for today was to create a front end where it would be possible for new apprentices to write there reports in a program installed on their local machines.  At the moment, they are all using a [Lotus] Notes database installed on a domino server.  Although this sort of setup is not wrong, and even safer than installing everything locally, it is still not optimal because they only use one or two Notes/Domino applications and they do not always want to start up the Notes Client ( a thirty second start on a really good day, two minutes on a normal day, and ten minutes on a bad day) just to make a quick one minute change to a document which tracks their weekly activities for the appropriate agency.  Let’s face it, none of us wants something like that.

Today, I started this front end.  My job is primarily to get myself situated with WPF development in the hopes to be a choice to help the development of a program for company X.  The form that I am basing this front end on is not really busy or anything, there is the typical data that needs to be stated, such as for which dates this particular document will be used for, names, departments, and a block where the user can input what they did that week.  It is really simple and that made it ideal for a first try.  Opening up the main window resembles a word document where the user sees a normal page sized white area in the center, and on the left is an area with tiles that can be pressed in order to open the document that should be opened.  This makes for everything to be pretty simple without much extras.  I do plan on extending this GUI to be able to use drag and drop functionality to open other documents and so on.  As I said, this is only phase 1.

Basically, I am so impressed because I could go into Visual Studio today with a basic idea of what I wanted to do today and without any issues at all, I could effectively design this program and come up with a great prototype to show the bosses at the end of the day and say, “This is what I could do in nine hours time with almost no foreknowledge! This is something that has been sorely lacking in the past year.

All of this being said, I am really contemplating starting BudgIt completely over again, and making a brand new Windows based application where I can truly make use of the great things that WPF has to offer.  Even if this does limit the “customer” base to those who have a windows machine, I do not see that as a big problem.  Every Linux user I know has at least one partition for Windows or at the very least a virtual machine with Windows installed.  The downside to this would be relearning everything the C# way, and a lot of stuff that I have done is very specialized. I would have to relearn encryption, IO, everything.  But, that is needed anyway eventually.

Point of the day: Thank you microsoft for actually doing something right and offering a quick and easy way to impress myself and co-workers by creating Windows GUIs using WPF!




Gettings Started with WPF

It has been a very long time since I have taken any time to update this site.  About half a year ago, the webhoster account I had was somehow hacked and changed, so I basically had to start over completely fresh.  I have also been so busy with testing and stuff because my apprenticeship was over… no matter.  I have not really been taking care of this site for a long time due to a “rage quit” and life matters.

That being said, I just started a new phase where I am going to be getting to know a new way of programming user interfaces.  Up until now, I have been very swing oriented.  It just made sense, even if Java gui designs are not the most “up to date” or the coolest or the most windows OS oriented way of doing things.  For me in a time where I was new to programming it just made sense because everythings had its object and I used those objects and all was well.  It was consistant, fun, confusing, and messy.  I liked it.

Now, however, the time has come where I would like to expand my knowlege and get into the Microsoft C# way of doing things.  Basically, I found the following two ways to do things: Windows Forms, and Windows Presentation Foundation (WPF).  Of the two, WPF is newer and “more exciting”(?).

First off, coming from such a strict language as Java, C# feels like a loose language that does not fully respect the theory of OOP (object oriented programming).  And at first glance maybe it is possible to see it that way, but getting deeper into it, I must admit that it is not really so.  This, however, is not the point of this article.  I want to talk about WPF and Swing.

So lets jump into it and give a brief example of how I would design a main window in Swing.  First off, I take a piece of paper, draw out what I want, what should happen, what should be dynamic, what should be static, etc.  Then, with an understanding of what layout managers are available, I would draw out the different panels I need and mark out the best way to accomplish my mission with the different managers.  In the end, I always tend to use the same Layout Managers: GridBagLayout, BorderLayout, and every once in a while I’d put in a FlowLayout.  The GridLayout in my opinion was worthless, and a GridBagLayout took forever to set up and set up well, and then the code was nearly impossible to read afterward, not to mention that a complex layout could be multiple hundred lines of code.  Even I, who loves Swing and would most likely want to keep using it, have to admit that something like that is stupid.  This is one point where I would say that OOP is great, but there is no reason to be so into the philosophy behind it that I would want to have not only all of the controls, the layout manager and the panels, but also use a GridBagConstraints object to configure the whole thing.  It is just too complex and all of this is just because of a bit of philosophy.  So lets see how I think WPF makes this just a little better.

The user story is just about the same as Swing, I draw everything out on paper, mark up what I need, the highlighters run out of ink and I need to get some more from the corner store, come back, and before I know it I have a plan.  Well, good.  What do I do from there?  In WPF, Coding forms is “old school”.  Of course you can.  You can even, due to the “partial class” keyword, even go so far as to have all of the design in one document and all of the actions and stuff in another document.  No problem.  But that is still not the full power/annoyance/new stuff that WPF has to offer.

Instead of using C# code (that only “real” programmers will know) a form of eXtensible Markup Language (XML) is used to called XAML, eXtensible Application Markup Language.  Just the name is pretty cool.  It also has the advantage of being written by designers in a text file or other tool without a complex IDE.  When I look at a XAML document, I see all of the same sorts of definitions that I would expect to see in the code form of the window: labels, text boxes, column and row definitions, panels and layouts, but I see it in a well organized way without the confusing additions of code to select the right label, or code to set a dynamic color.  I just see what I need to see to understand the layout.  Then, when I look at the code for the Form or Window, I see the different functions that I need to make it look good.

Now, I am just starting out here, and I am not going to be able to say well how all of this works, but I do plan about writing about my process and hopefully get some good feedback.  I am going to, soon, write a short page on how to subscribe to this page in order to write comments, but for now please just write to me at my facebook page and I will get back to you.

Thanks for reading!

What is BudgIt?

What is BudgIt?  Well, to put it bluntly, it is a tool which I have planned to use to help me maintain a monthly budget.  But there is something that makes it different than any other program that a person can either buy or get freely off the internet.  “envelopes”.  Alright, I do not even call them envelopes in the program, but that is, in essence, what it is.  I grew up with, and even am good at, taking money that I get on pay day, putting it in an envelope marked with a specific topic, and using the money in those envelopes for the planned topic.  This could be for a vacation, electric bills, or annual car insurance payments.  Whatever.  It does not matter what you use it for.  The main thing is that you use it.

I first wanted to start on the program almost 10 years ago.  At that time, I felt that most computer topics were way beyond my understanding and did not even try to figure it out.  A family member had been studying to become a programmer and I had basically just asked if it were possible for that family member to write it for me.  Luckily, she didn’t.  Three years ago when I started an apprenticeship for application development, I was happy that I finally could start on it.  Since then, BudgIt has had many different looks and many different complexities.  Its first version was rather crappy but helped me understand the basics of the Java lanugage.  Once I understood more about object oriented programming, the program was rewritten.  Then, once I understood more about SQL, the next version had a better database structure.  This is a program that has seen many iterations, and will continue to see more.  Currently, I am working on the installation process and the many workflows.  I am getting away from singletons and starting to work on a larger, more complex, yet simpler to use factory class that controls all the different aspects of the program.

There is a lot waiting to happen here, and I am really happy that I can share the process with you all!