Archive for January, 2014


OfficeDesk-smTime at the desk has been limited this week. The extreme cold has listed Pittsburgh as one of the 20 coldest cities hit by the arctic polar vortex. As a result, My 7 yr old has been out of school both Tuesday and Wednesday and my over/under guess is that he will also be out on Thursday. We are due for another sub-zero with windchill morning. My time in the office has been limited. I have however, had time to finish doing some cleaning to my work desk. I’ve been trying to do a full clean and organise over the past month due to the fact that this is now my 24/7 work place. (If only I were getting paid)

But onto the progress. Software design is often an experience of two steps forwards one step back. Sadly, the one step back also usually consists of several O’Reilly manuals, a bunch of gSearchs, and of course documentation and answers found on StackOverflow. Today was no exception. Finally back on my desktop app for entering data I realised that I wasn’t just doing SQL puts to the database. I was also uploading graphic resources. These however were going into a directory with references being added to the database. Sigh, back down to the API level.

So today, I had to learn in Java (and to some extent on the Client level) how to compose programmatically an upload post and then correctly save it to my server. Now, I (as always) realise that there are probably simple libraries to do this and experienced Java, JSP, and LAMP folks will scoff at the likely banal process this is. I however hadn’t done it before so I had to teach myself. Happily, info was available in the form of a few StackOverflow questions, a couple of nice online tutorials, and a few hours later; my Poster test app is sending the requisite info and it’s causing a file to be saved. This isn’t finished. I haven’t actually put in some of the path and file directives and I’m not sure that the file is storing up in clean shape. But considering the fact that I have only gotten about an hour at the desk today; and that before that hour I didn’t know how to do this at all; I’m kind of happy about the results so far.

Tomorrow, I hope to have more time at the desk (even though the child is home again) and I hope to finally be done on the API level… for a while. Also, I will be having a conference with one of my “volunteers for credit counting.” What this means is that they’ve agreed to volunteer time in exchange for tracking hours and converting it to value once we see more funding. I’m incredibly excited to have this person working on the team because they have great business depth, incredible sense of organization, and a great working relationship with me to call me on stupidity when needed without taking a response of NO personally.

Things trudge, but I think we’re on track to keep moving forwards.

As always, if people are interested on helping out.. I’ve got plenty of work to go around.

I don’t get nearly that much done on the weekend with The Project. Sadly my back went out today so I found myself enjoying the comfort of my home office chair.

I managed to finish up the last of my API calls that allow me to start crawling back up the stack. As a reminder, I started on the end client with hard coded data. Then I went down and created an SQL based relational database to hold the data. Then I realised I needed an app to enter data. Then I realised I needed an API for the Apps to use.

So, thus began my love-hate relationship with Java and Tomcat. Both of which I knew next to nothing about.

Fast forward about 3 weeks.

The first version of the APIs are done. However, in checking the logs for the Tomcat server, I discovered some sites had been snooping around. I had hits from Wichita  Kansas, Brooklyn NY, and several hits from places in China. Needless to say, this made me just a little cranky.

So today, I got up close and personal with two technologies. Tomcat Addr Valves (which is like a Tomcat Firewall) and VPN. After a bunch of minor testing, I can say with (unlearned and naive) assurance; the net-facing service is now accessible by VPN only.

I wish I had more of a choice here; but I don’t. Until I’m ready to open the floodgates, I need to have access for people helping me who aren’t on my internal network while still having the resource accessible remotely. This seems to be the best approach.

Where does this put me? On Monday the first thing I do is gut the old client’s APIs in favor of the new ones. Then I start fixing up the data entry program. Then I start entering about two month of newer data.

Then we can start pushing on that client full speed again. Whee!

ftp-big-iconI’ve been updating my web hosting customers WordPress this weekend. Partly to move them onto new servers with new updates. In doing so I got to learn about ftp configuration on unix. It’s a bit more involved that I was expecting. Quite the endeavor.

Just a short update. Tomorrow we hopefully wrap up the overhauled APIs on the project and move back up the stack.

codingI’ve been fairly quiet on the blog the past two weeks. This has been because I have been head down in code catching up from the holidays and being sick. I know all to well how abstract and vague I’ve been on what The Project is. I’m still shooting for a grand unveiling upon the ides of March. (March 15 for those who read not the Shakespeare)

I however do not want to be without any information. So I decided to play the magnifier game. This is the game where you show someone a picture of a common object through a magnifying glass and let them guess what it is they are looking at. Granted, that’s not my intent. I know what I’m showing is intentionally obfuscated to hide The Project’s intent.

However, I want to show a checkin from one of the classes that I did today to talk about what’s going on.

I’ve make no secret that this project uses a database to manage the content and Java and Tomcat to serve as a buffer to clients. Today, I am working on the database upload abstract class. In revamping my Java Servlets this past week, I have managed to completely abstract the query command class to the point that I can create any pre-packaged SQL query on the database into a 4 line subclass. This subclass can handle variant queries, compares, subqueries, and most importantly documentation on the return. This work made me very happy.

In pushing data up to the database there is more work needed. I have to verify that the call is including the correct information. I have to make sure that the subclasses have defined the necessary info to check. (So subclasses will be closer to 10 lines instead of 4)

Effectively, a push command should identify the table in the database, the usable column names, the required column names. And of course error check and return the response in a consumable way.

Below is my checkin comments from today’s abstract Class work. (Note there are redactions)

(Ah, the fun of Java)

imports java.util.List
adds ivars
	MUST BE OVERRIDDEN List requiredHeaders
	MUST BE OVERRIDDEN List usableHeaders
	String sqlQueryHeaders (for building sql update)
	String sqlQueryValues (for building sql update)
doSQLQuery() now doSQL()
	setRC not setRS with executeUpdate instead of executeQuery
goGet()
	Sends a formatted json error response (put, not get)
validateSubClass() (new)
	Checks to see that there is at least 1 usableHeaders
	Checks to see that there are no more required headers than usable headers
	Checks that all required Headers are in usable Headers
	Checks that there is a table conversion equiv in getDbaseTable() {below}
	Throws Exception (Programming error) if any of these cases fail.
validateRequest() (new)
	Verifies that required headers are in the request http Header
	Returns first missing required header if failure
processHeaderPair() (new)
	examines each HTTP header pair
	searches for headers that are: Package.Command.usableHeader
	converts them into caseCorrected usableHeader and Value
	Appends them into Strings for use in SQL Update request
getDbaseTable() (new)
	converts servlet full DNS name into table in Database
	returns null if not set.
doPost() now doPut()
	Adds failNote as a return from validateRequest()
	Calls validateSubclass()
	Calls and evaluates validateRequest()
	Runs ProcessHeader() while iteration headers
	Builds SQLQuery (Should be update)
	Calls doSQL() and evaluates
	re-Enables SqlResult display in output
	ErrorIn -> ErrorLoc
	Shows failNote

On top of this, since you can’t test a PUT command in a browser; I’ve had to write a mini Putter app on my Mac. Let me assure you, hopping back and forth between Cocoa for OS X in Xcode and Java for Servlets in Eclipse can be a bit of a mind scramble.

This has been a personally hard week for The Project. Iin moving the data structures to MySQL as a database I had to also start developing Java servlet code. The reason for this is that it creates both the ability to have a Web-API for any number of clients: iOS, Android, Win, Mac, etc… while at the same time affording more ease for Web functions.

mgbUnfortunately my Java and Servlet knowledge were (and likely are) still lacking. The problem is that when you start a new programming environment you basically create sample code to test what you are trying to write and then adjust that code as you see success. Then you build on top of that. This sounds like a good idea at first and then you realise, that you are in fact building an upside down pyramid.

You learn one thing and you carefully build on top of it. This lets you learn a few more things so you balance them on top of the one thing you started with.  At some point you have to realise that you can’t build any higher because it’s all balancing act. This is where architecture comes in. Architecture takes the tools and designs a strong foundation. It designs a good skeleton and lets you put things where they best fit in.

All this CS theory sounds great in general; but at the same time you are trying to get a product done. This past Tuesday I hit a roadblock. The way I had put my Java class together, there was no easy way to add the next function. For those with understanding; I was dumping EVERYTHING into one class. I’ve been doing Object Oriented Code for a VERY long time. I knew how wrong my code was (in design) but it worked and got what I needed done.

So I was left with the very hard process of:

“Do I keep shoe horning in, to get a working version OR do I use what I have to build into something designed from scratch and put me back about a week?” This is the ‘Ooh, Shiny’ that as an engineer it’s very easy to get blown away by.

  • The project started with a client and hand build data. (Working on the client)
  • Then the data moved to a database. (Drop client work on MySQL)
  • Need to add data remotely to database (Lock in database, make data client)
  • Now a connector was needed between the clients and the database. (Web service, go to Tomcat, Java, Eclipse, learn new tech)

Of course the actual product client hasn’t moved in two weeks as far as code. The data entry client ramped up last week, but the connectors aren’t there.  So, the fear is not putting so much into one that we don’t move forward with the actual Gem of the lot.  This week I had to decide… how do I proceed and will the decision be right or wrong.

On the one hand it was ‘keep pushing forward and working around the problems being created.’ On the other it was ‘Stop, learn, regroup, rewrite, take the hit.’ And this decision was going to leave me unhappy due to the cons on both sides.

After two days of being in really crappy head-space over this, I realise that this is my product and unlike many of the companies I have coded for: I want it RIGHT. I do NOT want it RIGHT NOW. The dates I set for release are still somewhat arbitrary. Better I be happy with what is under the hood.

Digression. When I was 21 years old my father bought me a 1970’s red MGB convertible (Similar picture above). This thing was beautiful. It was missing some mirrors and had no seat belts (some did.) My father managed to snag this beauty for $800. My dad also never actually looked at the condition of the car. When we opened the hood we saw the electrical had been ripped out and replaced with speaker wire. Half the gauges didn’t work on the dashboard (including Oil, temp, and Fuel) The car also didn’t have a starter button.  I could ramble on telling stories about this car that I eventually named Truddi due to the car’s penchant for having multiple personalities. The point is that the car looked beautiful, but it had horrible guts. There is the right way to wire a car and a wrong way.

While you may think, “Well, aren’t you just ripping out the wiring and redoing it?” The metaphor here is that I am making sure that what I put in there from the start is correct, and not just a pretty outside with horrid innards that don’t belong. And you can believe me that I’ve been asking myself these questions and fighting both sides of the battle.

(long sigh) Well, enough procrastination. Time to design and write some Java from scratch. (But profit from a distributable JAR)