Done log Android app

I have just published (pending review) my second Android app to the google play store. It's called Done Log (code on github). The purpose of the app is to allow a user to enter text log entries, and then be able to review past logs.

It's the initial release, so development is still in progress, but I think it's a somewhat useful tool already - which is why I published it.

It didn't take me too long to build the app, probably just a couple days total programming time (spread out over a couple weeks).

I hope that I can find some time to add some major features in the future. These include all the major buzzwords, like syncing data to some cloud storage, searching with autocomplete, and visualizing with dynamically created charts. It's part of my larger goal of being able to recall a lot more information about myself on demand.

But that's for the future, for now, version 0.1.2 is released (pending Google play review).

Cutting Glass

A while back, we bought a light fixture from an outlet store. It was missing a bunch of glass pieces, which meant I could buy it for a discount, and that I had a DIY weekend project on my hands.

I ordered a whole bunch of pieces that were close to the sizes I needed from frame destination. From these starting pieces, I planned to cut the glass to size.

I had zero experience cutting glass before, so it was a bit scary. I was afraid that I might cut myself, create a huge mess and end up with cracked useless pieces of glass. I watched a bunch of videos on youtube, like this one, then I bought this cheap glass cutter, and just started scoring and cutting. I didn't need to be perfect, thanks to me ordering some extra glass and because the edges of the glass are hidden in the final product. In the end, after about a day of work, the project was done.

So, how does cutting glass compare to my usual coding weekend projects? They're awfully similar. Both require you to take some time and research about tools and best practices. Both are painful to do, but rewarding when you see improvements and progress. So, I approached this glass cutting project the same way I do coding (little by little). I started with some easier cuts and marvelled at my success or reflected on my errors; then I went at it again and again until I was done.

I love being a programmer, software engineeer, coder. I think it helps me whenever I do anything. And whenever I spend time working on something else, I find myself using the lessons I learned while coding. Hopefully I learned something while I was cutting glass today that helps me become a better coder.

For those interested in glass cutting, here are some of my personal notes:

• I didn't use any oil. This was a one-off project so I didn't care too much about maintaining my $3 glass cutter.

• I found a long hard cover book as a good tool for helping cut glass. I first used it as a straight edge to make nice long scores. Then, I used the book to hold the glass while I was cracking the glass. The book helped me apply even pressure while protecting my hands.

Log Me

I love logs. The other day, a colleague asked me about a conversation we had several months ago. The conversation was with another colleague who had since left our team.

I could barely remember the project, so I didn't really remember what we had discussed back then.

Thankfully, I'm pretty diligent about keeping notes and logs of my activities at work. A quick grep search brought me to the relevant notes and I was able to dig out what we spoke about. Also, re-reading the notes helped me remember a bit more about what we were thinking at the time.

Our brains have amazing recall, but a little external reminder can help our brains perform even better.

I've been pretty good at taking notes at work, but I've got to get better at taking notes in my non-work life. With our ubiquitous set of technological tools, it seems possible for me to log everything about myself and to essentialy not forget anything.

Schooled

Learning is a process for me.

When I initially hear of a new concept, my reaction could be any of the following: surprise, awe, doubt, indifference, etc ... Regardless of the initial response, I typically don't have a real firm grasp of the concept just yet (even if I think I do). If I try to use the concept, it would be mostly hand-wavy, simplistic or clumsy.

That's where most new concepts mostly end for me. I am vaguely familiar but I don't really have a good grasp of it.

But sometimes, the concept is prevalent and it comes back to me. So I read about it or hear about it again, either actively or passively. I start to see some interesting subtlelties that I didn't initally realize. I come to appreciate the concept more and more. Because I have a better idea about it, I become comfortable and use it regularly. And befoe I know it, I begin telling others why I think this concept is interesting and useful.

In the world of programming, there are lots of concepts. Some of them have taken me a long while to learn. Here are a couple examples of things that have taken me a while to learn: Object Oriented Programming, Agile developement, and Unit Testing. For each of these, I thought I understood the concept pretty early on. But as I look back, I can see that I had a lot to learn about each and that I've slowly become better at each of them.

For me, learning is a process. It requires listening and reading, doing and teaching. It needs repeated attempts spaced out over time. Oddly, it often requires me to do other things for a while, so that I can see the concept in different lights.

So, learning can take some time. Lucky for me, I like learning. It's one of the best things about being a programmer. I'm always being schooled.

Ode to Android Studio Updates

It's Saturday morning, and I'm awake before the others.
I'll add a little feature to my app, before the day begins and I get bothered.

Andriod studio is opened,
behold, there is a new version!

It's in the stable branch,
so I hope for the best.

Download, install and restart
There is no trouble so far.

Try to run a project -
Oops, esoteric bug is blocking.

Stackoverflow I go and eventually fix what ails.
Time for the quick update is all but lost,

That's where the programmer days often end up.

Weekend android warrior

On Friday night, I thought it would be cool to have an app where the user could set up a series of alarms. I would set up the alarms to manage my workouts. For example, do jumping jacks for 1 minute, break for 10 seconds, do pushups for 30 seconds, etc ... Maybe it could be used in a pomodoro like system or even as a day planner. Going back to the minimal viable version, it would just be a list of items with associated time durations. When you hit 'Start', the timers would clock down in order.

Rather than looking for an app that already does what I want, I figured it might be good to try building it on my own. I haven't done any Android development in a while, so I'd like to pick it up again to see how what's changed. It would be fun to work on this project because it's simple and thus easy to make progress in.

When you start working in a new technology stack (or one that you haven't worked in for a while) everything seems to take longer than expected. Since I hadn't touched Android Studio IDE in a while, when I opened it, it had a few updates for me to install. I then fumbled around with testing in the emulator, before I remembered that using a real device is immensely faster. I also spent some time trying to use the Android designer before giving up and updating layout xmls by hand. Everything, even the most basic API calls, seemed to require a google search to make any progress.

After a few hours of work, I got something working. It's a working app that (for now) has two items (alarms). You can change the description of each and the duration of each. Then the timer will count down using the sum total of the durations. It's obviously missing a lot of features, but I'm happy I got started on the project. Because getting started on project is always hard to do.

Getting healthy

Lately, I have been trying to be healthier. Here's what I've been doing.

In the mornings, I have been doing quick, high intensity 15-20 minute workouts. I've been trying a few different things. Sometimes, I watch and follow a workout on Youtube. One source that I like is from https://www.youtube.com/user/BeFit. It's hard enough to make me tired (hopefully it makes a difference), but quick and cheap enough that I keep on doing it.

On the weekends, I have been going on runs. I usually run for just 30-40 minutes. I tried some running apps, but from now on I will track my runs with my new fitness tracker, the Fitbit Charge HR.

I've also been going to some classes at the Fhitting room. Classes are pretty expensive, but I think they are worth it.

I also started using a standing desk at work.

I don't have much more to say about this now. I just wanted to note it somewhere that one of the things I'm prioritizing these days is my health.

Starting Plopper

A couple of weeks ago, I started building an application with Electron. After a couple of weeks, I'm still enjoying developing in it.

It's a hobby project named Plopper. It is a tool to help you organize ideas. I'm thinking that it will be to graph structures what trello is to list-of-lists.

Progress has been ok. Translation: I haven't been blocked so badly that I wanted to give up on the project.

I'm not an experienced web developer, so I'm always getting tripped up by one thing or another. For example, when I was using the Node.js file system module, I was stupidly expecting the async tool to work in a synchronous manner. Let's just say that it was a good learning and debugging experience.

There have been more fundamental things I'm not sure about either. I am still not sure on how to manage the state of my application. When a user interacts with my application, I can save the state in long term storage in a file (probably a database in the future), but what do I do for intermediate state changes? For now, I've resorted to using some global variables that are around for the life of the application run.

I think the success of my application will depend a lot on the graphical user interface. If it's simple, intuitive, snappy and fun, I think it can work. So, I've been playing a lot with the html5 canvas. You are given rudimentary tools to work with the canvas, like drawing rectangles, lines and text. It's basic, but easy to understand, so I like it. It seems like you could nearly render an entire application using the canvas alone. I'm still feeling out how best to use the canvas.

El Capitan is good

I upgraded to OS X El Capitan. So far, I am very pleased.

The first noticeable improvement is that my laptop, Macbook Air 13-inch, Mid 2012, works much better with DisplayLink. I am currently using two external monitors, Dell U2410, at 1900 x 1200 resolution each with the laptop in clamshell (closed) mode. I can see that the screen has been turned off completely. In previous OS X versions, the laptop had to remain open and 1 of the external monitors would eventually just stop getting a signal after some time. I have only seen consistent good behavior.

The second noticeable improvement is something I might just be imagining. I think the amount of free disk space that I have has gone up by a few GB. Usually upgrades mean more disk space consumed, but I don't think that happened to me. Maybe I don't remember exactly how much disk space I had used before, and this is flat out wrong. In any case, the disk space consumption hasn't gone up noticeably, so that's good.

I have been a bit underwhelmed by the 'snapping' features for window management. It requires use of a mouse and clicking on the little green icon on top of a window. I'd rather have some keyboard shortcuts that do it for me. For now, I'll stick to using Spectacle.

I have not noticed any negative have only noticed improvements.

Free Time

The weekend is approaching, and fortunately, I don't have any major obligations. So, I've started to think about what I'd like to do.

Outside of coding, I'd like to go for a run on one day and go to the gym on the other day. I also have to put together a desk, and do some other household chores. I'm looking forward to doing all of these, because it'll make me feel great when they're all done.

But that still leaves me a good deal of time to do some coding.

This week I have been completely humbled. I saw some demos of other people's projects at work, and they were doing some amazing things. I also was browsing some electron based projects, and these were mind-blowingly cool as well. Seeing these projects initially brought me down. What's the point in starting a project that won't ever be as good as the ones that other people are doing? I won't ever create something that someone else hasn't already done better than me.

But, there's no point in wallowing in that sort of pity party for long. I think it's better to use those as inspiration to keep working.

I think the key is to not think too much. If I think too much, I get some type of paralysis, and I never get started on building something. This weekend, I'll try to do a mini sprint or mini solo hackathon where I force myself to build something. When it's all said and done, it may be throw-away code or it might be a building block to something bigger or it may be the inspiration for the next project. In the end, I know I will create something, which is better than just thinking about it.

Trying out Electron

I haven't tried out using a new language or tool in a while. I also have a new application in my mind that I'd like to build. So, I thought it might be cool to try out out this thing called electron.

What is Electron? It is a way to write desktop applications using webby languages (like html and javascript). But wait, there's more. You also get access to API's to the native operating system. And supposedly, those API's work in different environments, so you might be able to get the holy grail of writing once and then running everwhere...

So, let's give it a look. You start by asking node package manager to install electron.

npm install electron-prebuilt -g

When I tried this, I got some warnings about having an old version of node. It's been a very long time since I've used node, so that wasn't surprising. So, I uninstalled electron

npm uninstall electron-prebuilt -g

and then hit the keys to update node.

npm cache clean -f 
npm install -g n
sudo n stable

I brought myself up to node-v4.0.0. Then I ran the install for electron again, and it completed with no warnings.

I followed the quick start guide to build a simple hello world application.

Some initial impressions:

• This hello world app was simple and readable, as they all should be.
• The whole stack feels thin and light. In contrast, I remember trying the MEAN framework out and finding it be ridiculously heavy. There were tons of files, it took up a whole lot of space, and there were lots of abstractions. That framework felt so heavy to me. This one just feels so much nicer.
• This hello world getting started app doesn't really do much at all. I'm excited to get something going that does just a bit more.

It was a good start, and I'm excited to continue working with Electron.

New Moto X Pure Phone

I just bought a new phone, the moto x pure.

Here are some thoughts.

It took about 2 weeks from order time to delivery time.

It was completely painless to get it working with my verizon plan. I brought it in, the person at verizon looked up the phone id in the settings and installed a new sim card, and it just worked.

As I was setting up my phone, it started to get pretty warm. This is something I should monitor.

I haven't really started using the motorola specific features that I heard were pretty good. One thing that I find a little annoying is that the screen never seems completely off. It keep waking up. I think this is a featue, not a bug, so let's see if I can get used to it.

The phone feels pretty big. When I put the free bumper on, I had trouble holding it in my hand. But, I started to get used to it. Importantly, it pretty comfortably fits into my pants pockets, so I think it'll be fine.

I keep a lookout for the new Nexus 5x. If: the specs compare well, the battery is just as big, and it will work on verizon, I may swap my phone for this moto x.

I'll start using it for real in the next few days. Here's hoping for the best.

My Daily Routine

For the past two weeks I have been following a daily routine, and I think it's been a success. At the end of this blog entry, I'll post the current version of my daily routine.

For anyone who doesn't have a daily routine written down, I'd highly recommend doing it.

I have always had a normal daily routine (more or less), but I didn't always write it down beforehand. By writing it down, you are forced to prioritize what you really want to do during your day. Unsurprisingly, most people prioritize doing positive things. It's similar to setting a new year's resolution in that most people aspire to do good things.

But unlike new year's resolutions, daily schedules are pretty easy to follow. In daily schedules, you are forced to list out tangible goals. Instead of resolving to do abstract things like 'lose weight', a daily schedule should have tangible work items like 'drive to gym' or 'go for run'. The constant reminder of a daily schedule makes it easier to stick to your plan.

But even if you find that you failed to do something in your daily routine, you can always shift things around to make it work for you, starting tomrrrow. For me, I found that I initially packed too many things into my mornings, so I shifted some things to the afternoon and it's been working better. If my priorities, commitments, or aspirations change in the future, I'm only 1 day away from revising the plan and trying out the new version. Hopefully, you can quickly zero in on the plan that works best for you.

Planning out the day in advance is important. It makes you more productive. There's less ramp up time getting started on something, because I already decided what I want to do next. I also worry less because I know that I sometime in the day, I will take care of everything I want to do.

To help me get through the routine, I use a bunch of tools. The most important ones for now are youtube (where I find home workouts to follow), anki (an android app which I use to create flashcards for studying Korean), and career cup (where I get programming puzzles to practice and study).

I'm now on the lookout for a simple Android App that I can use to help me follow my routine. If I can't find one that suits my tastes, I might just buld something myself. If so, I'll have to add it to my routine.

And without further ado, here's the latest version of my daily schedule:

• 0630-0635 wake up
• 0635-0730 study (these days it involves studying algorithms)
• 0730-0800 workout
• 0800-0810 shower and get dressed
• 0810-0825 walk the dog while doing korean flashcards
• 0825-0835 walk to work + listen to podcasts
• 0835-1230 work
• 1230-1300 lunch
• 1300-1745 work
• 1745-1800 walk home + listen to podcasts
• 1800-1815 walk the dog while doing korean flashcards
• 1815-1845 yoga and meditate
• 1845-2000 dinner
• 2000-2030 create new korean flashcards to study
• 2030-2130 test what I have been studying in the morning (algorithms)
• 2130-2200 miscellaneous
• 2200 sleep (8.5 hours)

Going Towards the Pain

I've noticed a funny pattern in my software development life. It is, Working on the worst things can be the best. Here's a story of one example in the pattern.

After a few years of professional software development, I was growing more and more dumbfounded at how difficult it was for us to deliver code. Our team was productive, but some things just seemed harder than they should be. For example, every time someone wanted to update an existing project or roll out updates, it seemed to require a lot of manual handwaving, hope and guesswork.

My manager sensed my discomfort with this and told me to embrace it. She told me to think hard about how we can improve the quality of our software and begin attacking it.

I started by writing a best practices documentation that standardized things for our team. This included simple things like doing code reviews for any change, using branches for parallel development, writing good unit tests, etc ... I wrote scripts to help automate some drudgery. I wrote example code for our team to learn from and model. Over time, our team began adopting more of these practices and I think we have become more effective.

So, by attacking something that was causing our team pain and difficulty, (surprise, surprise) the problem was mitigated. Additionally, I found a lot of interesting things along the way. For example, I learned where unit tests worked best (and didn't work). In fact, the boring, mundane thing became interesting (to me at least).

In the process, I also became the go-to person for all things related to improving the quality of our software. By focusing on one small niche of improving the process of delivering code, I got to learn from a lot of other people who wanted to improve their code for their specific workflow.

I think this process of picking out something that you find annoying, painful, boring or generally sucky and then working towards fixing it is a good approach. It's sort of the opposite of following your passion.

In time, the thorn in your side might become your favorite pet project.

Product Reviews

For the past week, I have been moving into a new apartment. While doing so, I switched internet providers and realized that I needed to get a new cable modem and router. I eventually settled on the TP-LINK Archer C7 AC1750 Dual Band Wireless AC Gigabit Routerand the Netgear DOCSIS 3.0 High Speed Cable Modem (CM400-100NAS).

My choices were largely influenced by http://thewirecutter.com/. This is the best review site I have ever seen. For the router, I just went with the recommendataion given in http://thewirecutter.com/reviews/best-wi-fi-router/. Easy.

For the cable modem, http://thewirecutter.com/reviews/best-cable-modem/. I went with the runner-up. The winner supported lots of different internet providers, which wasn't important to me. The runner-up was in stock at a local best buy, so that's what I went with.

I like how the reviews take into account reviews/complaints found on other sites, like amazon. This is something I would normally do, but thewirecutter does it for you. There isn't a review for every single item under the sun, but if the wirecutter has already reviewed something that you are looking to buy, I highly recommend it for its depth and ease of understanding.

Trying out Flask

I have been building a new web application, called Done Notes.

To build the application, I have been playing around with some new toys:

• Flask is a web framework for Python. It's supposedly a micro-framework, but it seems to do a lot for you. This makes it easy to do things, but hard to debug.

• Postgresql is an open souced sql database. I have been playing with no-sql data stores, so it's very comfortable to return to using a relational, sql-based database.

• Heroku is a cloud application platform. I haven't really had a need to debug things on the cloud or stressed the resource limitations. So far, it has been just fine.

• Alembic is a database migration tool. This tool connects my data models with database migrations. It generates upgrade and downgrade statements that are real sql statements (or very close to them). It makes version controlling your database changes easy to do.

I think it's nice to work with new tools once in a while. It can be frustrating, but it often helps you think differently.

Keeping Busy

In an effort to improve myself, I have been trying to write code every day.

After 41 days in a row of github checkins, I forgot to check in something yesterday. The chain is broken, and thus my current streak is back at 0. Sure, it was a modest streak. Some people have done much better. But it was the longest one I ever had.

During this past streak, there were lean days. On those days, I ran out of time and just did something small to keep the streak alive. Yet, there were many days where I did something of substance.

I ended up improving http://englishtokoreanforum.appspot.com/ from a barely functioning prototype to a semi-usable app. It's still not really production worthy, but I use it fairly often and it's making my life easier.

Today, I'll start the next streak. Let's see how long it lasts.

How to handle the new

When a new required to a project, or an unknown bug is discovered, you have a few ways to address it.

Option 1: Hack a fix.

Warp the existing code to just make things work. Maybe you add an extra hard-coded if/else check, or you make a database column mean two different things depending on what piece of code is reading it. Get the code to compile, build it and ship it.

Option 2: Do it right.

Think about what solution you would've built had you knew about the 'new' requirement or possible bug beforehand. Maybe you would've designed your database tables differently, or separated your code into two separate services. Whatever that ideal solution is, build it and migrate your old system to the new one.

Option 3: There is no spoon.

Build something that renders your client's previous wants moot. Since you're building something that is two steps ahead of what the client (and your competitors) are even dreaming about, you don't have to worry about what the client thinks they want.

So what's the best option? It depends. If you find yourself only doing one of the options, you are probably missing out on something.

One man show

At work, we've been adopting the Scrum Methodology, and I have reluctantly become the Scrum Master on our team. I have plans to retreat back into a developer role, but that's another story.

At home, I've continued to work on the English To Korean Forum application, where I am the Product Owner, Development Team, Scrum Master and the only Client. As the Product Owner, I just decided to reduce the scope of the application significantly. As the only member of the Development Team, this lowered the the complexity of my application, which made me happy. As the client, the application is simpler to use and it just makes more sense (to me at least).

I suppose this is the ideal that scrum teams are working towards where the minds of everyone on the team are completely in sync.

Working On My Legacy Code

A few years ago I started a project called the English To Korean Forum. I thought it would be a good learning experience, and at the end, I'd have a useful application for myself.

I don't remember why, but I eventually stopped working on it. The application somewhat worked, but it didn't have all of the features that I dreamt it could have.

That is the fate of many projects. Started, but not completed. Hoped for, but not fulfilled.

Last weekend, I had an urge to work on that old application again. I opened the folder with the code with some trepidation. Surprisingly, the code wasn't so bad. After reviewing the README, I was quickly able to start making enhancements again. There were some things that I wasn't doing back then like using a Makefile or writing unit tests, but the code was relatively comprehensible.

So, last weekend, I found out that working on my own legacy code wasn't that bad.

Stop Poking Me

I've been working on a home renovation project, which has been hard. It is tiring for a lot of reasons, most of which I won't go into. The one thing I'll mention is that I have to deal with a lot more email and texts throughout the day than I am used to. This communication is necessary, so I have no choice, but to deal with it.

As I deal with this new influx of communication, I realized I am getting a lot of other unsolicted email. This unsolicted email causes a lot of false alarms as I look for email that I actually care about.

So, over the weekend, I did some things to reduce the noise and save myself some time.

Unsubscribe from as many emails as possible

I went through my email trash, and found as many auto-emailers that I could find. For each, I unsubscribed. It usually required just a click or two for each auto-emailer: not too bad.

Turn Facebook notifications off

I turned off all notifications from Facebook. I tried to just reduce it last week, but I was still getting 'pokes' and other completely irrelevant notifications. So I turned it all off. I don't want to be a complete insensitive recluse, so I replaced it with a new IFTTT rule that sends me an email once a week saying "Check your facebook". I figure checking facebook at most once a week will be more than enough.

Changed to firefox

Finally, I've noticed that the Chrome browser on my Android phone and my mac computer has been very slow. I haven't measure it, so this is completely subjective and ancedotal. Over the last weekend, I have been using Firefox on all of my devices, and it definitely 'feels' faster. I'm switching for now, and hoping that it continues to work better.

Last Man On Earth Review

I eagerly awaited and eventually watched episodes 1-3 of the Last Man on Earth.

I expected it to be funny, and it had some funny parts. But overall, I am totally disappointed.

I had hoped that this would be a show about ingenuity, perseverence, failures and triumphs. Instead, after three episodes, it's more like a romantic comedy. Who would have guessed that the Last Man on Earth would find himself in a love triangle?

At any rate, here is what I hoped the show would look like. The last man on earth is a regular dude with no special skills. He finds himself alone but surrounded by modern technology around him. Unfortunately, without someone maintaining things, he can't just depend on anything just working. So, he has to learn how all of the infrastructure of modern day civilization works. Hijinks can still ensue as he burns down a power plant or blows out an entire city grid. But with all of these defeats, his eventual technological triumphs will be even sweeter.

Is that a boring show? I don't know. I do know that if the show were more Survivorman and less Friends, then I'd definitely be tuning in for episode 4.

Your Life's Work

Everyday you are working on your life's work.

And your life's work doth not wait. Whether you are aware of it or not, you are contributing to your life's work now. It's a sobering truth.

Whether you are building something new, learning about functional programming or browsing social media, it is all part of your life's work.

The trick is, some things seem to accumulate whereas others just evaporate.

As programmers (and humans in general) we have a chance to build things of substance. I hope my life's work amounts to something of great substance.

How to pick someone up at JFK airport

I had to pick up my mom from an international flight arriving at JFK airport in New York. For future reference, here are the steps that you should take to do this with the least stress possible.

1. Before the flight, tell the person you are picking up to call you when they land.
2. Drive to the airport, arriving at about the same time the flight is supposed to land.
3. Go to the cell phone parking lot. This is just an empty parking lot that you can wait in.
4. From the cell phone parking lot drive to the terminal where your passenger will arrive. Pick out a landmark where you can tell your passenger to go to, like "Passenger Pickup Area C". This is just a test run (since your passenger has not actually called yet).
5. Go back to the cell phone parking lot. Read a book, listen to music, relax and wait.
6. When your friend calls you, tell them to call one more time after they have gotten through customs and picked up their bags.
7. When they call, tell them to go to the spot you already checked out, like "Passenger Pick Up C".
8. Pick them up and go home.

Build something new every time

When you work on a project, think, "How can I create something so that I never have to re-write this same program again?"

For example, say you are asked to setup a process that retrieves a file from a ftp site, reads the file and updates a database. Instead of writing something that just does the job, you should try to write a generic ftp retriever, a generic file reader, and a generic database updater.

Then you data-drive every piece of the process to deliver a solution for this specific problem. When you need to work on a new (yet similar) project in the future, you just have to change the configuration and data-drive your next process.

If you follow this practice, things may initially take longer to get done. It's much harder to write generic code. It's possible that you'll never reuse this generic code again, which means you wasted your time. But I think it's more likely that if you needed to do something once, you'll need to do it again.

So, you may or may not be more productive. But I think you'd in general be happier, because writing new programs is good for you. It will force you to think and learn. You won't get bored by the tedium of doing the same thing over and over and over again ...

I guess what I am getting at is simplay another way of saying keep things DRY, and save your key strokes for something new.

The Clueless Programmer

When you start programming, you write or copy code, and there's no way you can understand how it works. You just have to accept and hope that some other programmer put enough time and energy into the language that the text you plopped into the editor will somehow magically work.

Over time, you learn more and more, and after some tipping point you begin to understand most of what you type. In the least, you can describe what would happen to your program if you modified any given line of code. So, you get to the point where you are code literate.

Being a semi-literate coder will only take you so far. At some point, you want your code to do more. You want it to perform faster, with less resources. You want it to be clear, concise, and understandable. You want to reuse it for other applications.

So you start asking yourself low level questions like "which smart pointer should I use and should I be passing it by reference?", and head in the clouds philosophical things like "who should really own this object"? Through these questions, you realize that there's a lot that you don't know.

And so, you find yourself in a familiar place, thinking that there's no way you can understand how it all works.

Lucky for you, you've been here before.

Building a Sudoku Solver

Sudoku Solver

A couple of weeks ago I tried my hand at building a game, Tic-tac-toe. Today, I finished building something else. I wrote a command line program that solves Sudoku puzzles. The input to the program is a series of numbers representing a sudoku puzzle board, and the output is printed to a terminal screen.

What did I do?

I built the program in C++ with the help of 3 different libraries (google test/mock for testing, boost for handling command line arguments, and ncurses for drawing to the terminal). I had already used google test and boost before, so it was simple to use them in this project. Ncurses was new for me, but it basically worked right out of the box (after updating the link line and including the header). I think I could have written this program without any of these libraries, but it would have been a lot more painful and buggier.

The program is designed to have a MVC (Model, View, Controller) architecture. The model is the puzzle board data, the view is the command line terminal, and the controller is something that observes the model and calls the view to draw. TODO: Learn more about the MVC pattern. Then make my code conform the pattern better, or stop calling what I wrote "MVC".

The business logic of this program was to solve a Sudoku puzzle. The reason I started writing this program was to practice writing a backtracking dynamic programming algorithm. For the current version, I chose a pretty simple algorithm that walks through the grid cell by cell in order. It works for the few test inputs that I gave. However, there is lots of room for improvement.

What did I spend my time on?

I spent almost all of my time setting up the apparatus for the game - ingesting input, updating the view, connecting the components together, etc ... I spent very little time on the algorithm used to calculate the answer. Now that the apparatus works ok, (if I want to) I can work on improving the solving algorithm.

Takeaways

Building a real application can be a good way to learn, but it's easy to fall into the trap of only reusing techniques, approaches and tools that you are already familiar with. Unless you keep asking yourself, "is there a better way to do this?", you may never expand your skills.

Positive feedback is really important. It feels good to see your unit tests passing and your output displayed on some screen. That sense of accomplishment can keep you motivated when you are lacking the motivation to finish a project.

Resolution For 2015 ProgrammerDays

For the first team meeting of the new year, our manager laid out a high level overview of what he thinks we'll accomplish this upcoming year. The summary included some things that I was happy we'd work on, but it also omiited a few projects that I liked. This meant that some of the projects that I have been working on were going to end up in the vast graveyard of half completed computer programming applications.

I'm all for killing programs and applications that no longer provide value to our clients. Such projects become all bugs and no features. The thing that irks me is when things go unfinished. Due to shifting priorities, poor planning or something in between, some projects get started, but never make it to a completed state. That bugs me.

While I am somewhat subject to the whims of management at work (and must leave some projects unfished), at home, I have no such constraint. So, my new year's resolution is to finish everything that I start.

For example, this blog post is about to be completed, now.