Getting Organized and Low Maintenance
It's been a while too long since I've posted. All of the systems I've been building for the last 18 months or so are starting to tie together very nicely. So why has it been a while since I've posted??
Like I said, the systems are starting to come together, which means I'm getting really excited and I want to accomplish everything, but alas, I'm only one person. I have recently started using BitBucket to host my private repos. I discovered that their FREE accounts are limited based on # of contributors, not # of private repos like GitHub. I've always wanted to use GitHub but the majority of my work is not something I can share openly, and therefore I don't use it at all. Unlimited private repos is exactly what I need right now, and knowing that I can have up to 5 contributors (including myself) is a high enough limit for now. If I need more than four others I should be able to justify the minimal expense of $10/mo.
Anyway, the feature that has me the most excited is the built in Wiki. The real feature in there that I really love is the ability to clone the wiki to my local machine, edit it there and push it back to update the wiki. The other awesome thing is I'm now going to use Pandoc to build the Wiki in HTML format and load it directly to our VPS. Nothing against the Wiki in BitBucket, and I wouldn't mind making it public... but it would require me to have a lot of non-technical people creating BitBucket accounts just to view the Wiki, that's not easy to use for them.
Here's how easy pandoc was to get up and running.
Installing pandoc on my development VM (Debian):
sudo apt-get install pandoc
A simple command to convert one markdown (.md) file to HTML:
pandoc Home.md -o Home.html
The good news is, now that I know how easy this was to do, I will start setting up all of my documentation in these Wikis, and I will create build scripts using Phing and Pandoc to generate whatever documentation I need to make available. Simple, fits into my workflow, and easy to maintain multiple formats of documentation within source control. It also encourages me to load all my projects to BitBucket, because a) no cost, b) another place my source code is stored, c) makes it easy to collaborate as new developers come on board!
Life is good!
Talk Carefully At Home
I worked from home today and towards the end of the day Julie, my amazing fiance (update: wife!), said "Oh! I know what your next presentation should be!"
She ran and grabbed one of our massive sitcky-note flipcharts... and here's what happened.
No NoSQL For Me... Yet
If you work in any IT related field you must be ready to embrace change and new technologies. You must be willing to learn. Constantly. You must also be willing to think. Thinking critically and solving problems is the reason I get paid, and the reason I can pay our mortgage!
Anyone who works with data or databases has probably heard the term "NoSQL" more than once. I've read about it over and over and over. There are debates, cage matches, and more. I'm not going to talk about what NoSQL is or why it's good or bad. Personally, I think some very interesting things are happening with the technology and I will keep reading about it, but just because something is interesting doesn't mean it's for everyone. For example, I have gone sky diving and I'm addicted to the adrenaline rush and can't wait for my opportunity to go again. I also think base jumping is interesting, but I will likely never do that!
Maybe one day there will be a good reason for me to deploy an application based around a NoSQL database, but for now I will happily take advantage of ACID and the relational model.
My "FIXME:" Challenge
I have been working on getting a whole lot of our internal systems in place since January and all my hard work is starting to pay off. I'm constantly trying to improve my code and beef up my programming skills. I'm happy to say I'm the first to know that my entire code base is pretty crappy.
I'm happy to say that because I know how much better it can get and I know I've set myself up well to do so.
First: I've been pretty good in the past couple of months to put FIXME: comments in my code throughout so I can remember my ideas, and nag myself to fix them! I have also been pretty good about fixing the more important ones when I see them later, but the little ones I always let slip because I didn't have an efficient way to track them. But now that we've been using Mantis as our bug tracker for over a month, it's time to start entering the FIXME's in with everything else.
// FIXME: This isn't scalable. This will natrually be improved
// by simply pulling this data from the database. This will also
// simplify the maintenance between the build server itself and this
// library.
I will likely continue adding new FIXME's in the code because it's more fluid when developing, but as I enter them into Mantis I will simply replace the notes I left in the FIXME with a URL to the issue in Mantis! This should help keep duplication down a bit as well.
That's all for now!
Lots of Mistakes
I make a lot of mistakes, and I don't want that to change!
Mastodon