Returning to Semi Activity

Life seems to be calming down now that my youngest daughter is almost a year old, and I have noticed that I have the energy and attention span to start perusing interests again. In doing so, I have become re-acquainted with an old stranger that I have found absolutely inspiring. While the logical programmer side of me has been focusing on efficiency and productivity (not always practicing it, but trying to focus on it), I feel like I have lost sight of some of the important things that have made me me.

 Anyway, with that in mind, I hope to accomplish more in the coming days, and I hope to feel inspired to share those accomplishments, large and small. I also want to do some back tracking and share some of the projects I have actually been successful with. Turns out, when I pick a small enough project, I can actually finish it sometimes :D.

 Something that's very exciting to me is one of my first drawings in months, if not years. I always doodle from time to time, but when I want to draw, I have to get myself in a completely different mindset. I'm trying to stop thinking about lines and start focusing on construction. I've been trying to start with shapes and then slowly refine and add more details. Not only do I think that it's resulted in better work, but I have also found the process more enjoyable. Here is my latest drawing, but not one of my best from my recent works. It's a bit eerie, I suppose. But I'm also trying to remind myself that art doesn't always have to have a deeper meaning. Expressing yourself doesn't mean that you have to share something meaningful, or even portray yourself as deep. It really is Ok to just draw what you want to when you want to, and it's still an expression. I kind of learned that by looking at Jeremy Geddes art. Geddes is my current favorite artist, and while I don't want to say that his art has no meaning, his subjects just seem so far out there that the meaning escapes me. Or, if there is meaning, then I believe that he is choosing to draw what he wants to draw as a symbol for his intended message. Either way, when you look at his art, the lighting, the motion, and the contrast all come off as being very dramatic.

Well, my latest drawing is hardly full of any deep meaning. It's just a quick sketch in GIMP inspired by an artist/writer that I have gained an immense appreciation for. I mostly just want to share it because it represents a new drawing style for me that I never thought I would be able to accomplish. I have been calling it ICUCME:

Why I'm Giving up on Ivy (For This Project)

I have been spending a lot of my free time the last few months working on a card game for Android. By free time, I don't just mean "time when I am not at work," I mean "time while the baby is asleep, everything around the house that needs to be done is done, and I have not other social or family obligations to attend to." I have made a point to make time every week to work on it, but so far my best week has still been less than 10 hours of development time. Needless to say, I am looking for fast solutions to my programming problems, hence part of the reason I have chosen Ivy.

At work, I am a Maven guy. I was introduced to Ivy a couple of months ago by a consultant from Vaadin that visited the company I work for. What I liked about it was how easily it integrates with Eclipse, and how quickly you can pull in dependencies. I especially liked that I could pull in dependencies from the Maven repository, which I was already familiar with. A simple ivy.xml file has significantly less lines than a simple pom.xml file. At the time it seemed perfect for my goals, and for the first few weeks that I used it, I thought it was great.

Problems arose once I decided to split my application into two projects. I mostly did this for ease of testing, and because wrestling with the ADT plugin over what JUnit library I wanted to run my unit tests in somehow caused my Eclipse to break in a way that I couldn't figure out for a couple of days and eventually involved deleting my workspace and re-importing all my code in to fix. When I split my code into an Android project and a core project, I remember thinking "No problem, it should be a breeze to import my core project into my Android project with Ivy, cause Ivy's so simple!" Wrong. Let me share the issues I had while trying to achieve this that have led to me giving up on Ivy for this project.

1. Ivy Documentation - There are many complaints about the documentation for Ivy on the inter webs. In truth I thought the documentation was organized well. What makes it difficult to understand is that it is obviously written by somebody to whom English is a second language (at least, I hope that's the excuse!). At the time, I felt like this just comes with the territory of software development these days, and a documenter's ability to write in fluent English is not necessarily an indicator of how helpful the library is going to be. But now the dam is broken and the critiques are flowing. I frequently had to read sentences in the documentation multiple times to understand what was being stated.

2. ANT - Yeah, I should have seen this coming. During my honeymoon with Ivy, I found it so easy to use that I forgot it was a dependency management tool built for Ant. I wasn't thrilled about learning some Ant essentials to build my artifacts, but I had some experience and figured it was a good job skill to learn (although, I think I may have once lost out on a job opportunity partially because my one question for the interviewer during the "do you have any questions for me" section was "why are you guys still using Ant?"). A couple of friends who I complained to about this problem suggested that I use Maven to build my core jar, and import it with Ivy, but I felt dirty just thinking about that, and felt that I should use either one dependency management tool or another.

3. No SNAPSHOTS - This is where the love affair started to end. After getting my core library into my android project, and making my first change to the core library, I built my core again, and resolved my android project and.... my changes weren't pulled in. It turns out by default Ivy will not update a project, or your local cache if there is no change to the revision number. Their expectation is that for every change you make, a new artifact should be created, with a new version number. At least, that's what these paragraphs from their documentation suggest:

To optimize the dependency resolution and the way the cache is used, Ivy assumes by default that a revision never changes. So once Ivy has a module in its cache (metadata and artifacts), it trusts the cache and does not even query the repository. This optimization is very useful in most cases, and causes no problem as long as you respect this paradigm: a revision never changes. Besides performance, there are several good reasons to follow this principle... 

Some people, especially those coming from maven 2 land, like to use one special revision to handle often updated modules. In maven 2 this is called a SNAPSHOT version, and some argue that it helps save disk space to keep only one version for the high number of intermediary builds you can make whilst developing.

It then goes on to describe a property that can be added to your tags to make this work they way people from "maven 2 land" would expect it... which leads into my next point.

4. Ivy  Certainly Does Not Feel Simple - Looking back at the Ivy Home Page, it reads "Apache Ivy is a popular dependency manager focusing on flexibility and simplicity." Flexibility? Yes. There seems to be configurations for everything. Heck Ant itself feels like you're just writing a shell script in xml format. Simplicity I feel I have to disagree with. This being said, I'm not sure if a dependency management tool CAN be simple. Maven is no simple tool itself, and I recall spending plenty of hours, including weekends trying to get projects to build. Of course, at the time I was a junior developer who had never used a dependency management tool in my life. There are a lot of things that Maven does for you automatically that have to be configured in Ivy. By the time I read that in order to get my locally built artifacts to reload each time I resolve I would have to add and extra configuration, I had already had to write special configuration for things that work automatically (if not very easily) in Maven. This includes writing a special resolver in yet another xml file for resolving locally built projects (just happens in Maven), and writing up a publish task in my build.xml file to define how an artifact should be published, after writing up how to build the jar file (Maven just DOES this. It builds a jar for you and publishes it using the groupId and artifactId. And if the default way to built that jar is not to your liking, THEN you can configure it with the jar-plugin).

5. And Then There Were Source Jars...- The final straw for me was tonight when I pressed my trusty "F3" button while selecting a method from my core library. I of course expected to be taken to the source of that method, but was instead shown one of the coding equivalents of the dog from Duck Hunt laughing at you; The Source Not Found page. Oh, and no "Attach Source" button, with a brief message saying it's Ivy's fault you can't attach your own source. I spent the rest of my night looking up and reading multiple Stack Overflow questions from multiple people having similar issues on how to publish and then resolve a jar with a source classifier on it. At some point, this led me to my final reason for dropping Ivy for this project.

6. I Don't Know Ivy - Let's be honest, I hate it when people complain about a tool because they can't figure it out. Sometimes, that's not always the tool's fault. The real reason Ivy is not working for me is because I don't know it.  I could learn Ivy, but since my goal is to develop quickly, my investment in learning Ivy and Ant has long exceeded the time I was willing to budget for setting up dependency management. Later this week I will set it up using Maven because I know it, and am proficient with it (I probably could have set it up in less time then it took me to write this post).

With that thought in mind, I guess it's worth considering who Ivy is written for. I'm sure I will be corrected if I am wrong, but my understanding is that first there was Ant, then there was Maven, and then there was Ivy. I've seen some complaints about Maven, and I'm assuming that there were some long time Ant users who felt that Maven was too auto-magical for them and continued to use Ant. And now Ivy has been written for Ant users. If I'm correct in thinking this way... well, I'm not an Ant user, so I (currently) have not need to use Ivy. Maven works for my needs, and I'm more familiar with it.

I also think it's worth mentioning that I think Ivy is great for single project applications. I have every intention of continuing to use Ivy for proof of concept applications where I just need to throw together a quick, small app. As familiar as I am with Maven, I still feel it's a little verbose for small applications.

So, I tried to be as honest and fair as my experiences with Ivy could allow. Feel free to disagree in the comments, and let me know my level of ignorance for choosing to turn away from Ivy for dependency management.

Disabling Start Up Applications

This is a little trick that I've recently re-come across. I found this a few yeas back, but whenever I need it (usually when I am trying to fix somebody else's computer) I can never remember it. When I Google for "how to disable applications on start up" the only trick I can find is to remove them from the Start Up folder in the Start Menu. I'll post this here so I can always know at least one place I can find it, and hopefully others can come across it too.

Start Menu -> Run -> type in "msconfig"
Go to Startup tab
deselect annoying start up applications at your own discretion and to your heart's content.

Pencil Sketch

Just a quick sketch I did a couple weeks ago.

Extreme Pumpkin Carving

If you've never heard of extreme pumpkin carving, this link has some great examples. However, please refrain from looking at it until you've looked at my pumpkin so that mine doesn't look so bad.

I have been wanting to try extreme pumpkin carving since I first saw the infamous Predator Pumpkin, but I've been too scared to try it. I've never sculpted or carved anything before, but I'm content with my first attempt at it.

Now, this might look like the Creature from the Black Lagoon, but it was actually supposed to be Cthulu. Fortunately, my wife and her younger sister inadvertently helped my pumpkin look more like Cthulu with their pumpkins.

Kimberly was going for some weird geometric design that ends up looking like R'lyeh. And in case that didn't make it clear enough that this was Cthulu, the viewer would look at my wife's pumpkin and say "Oh, now I get it, that's Cthulu's flying cat!" Cause if Cthulu was going to have a pet cat, it would have wings.

Below is a couple of views of hastily carved wings and my original concept art.

Ok, now you can go look at that link.

Eliana

click to enlarge.

This is the result of a character design, that I tried to turn into piece that ended up as an experiment and learning experience. I originally drew Eliana as a Dungeons and Dragons character (Eladrin Warlord) for my wife. I thought that if I made her pretty enough and if I created a back story for her that would involve her being a princess that my wife would be willing to play. Fast forward a year later, I hadn't been drawing as much as I would have liked and I kept coming across this drawing. I felt that when people saw it they didn't see what I saw when I looked at it, and I had been wanting to try my hand at digital coloring so I decided to use this one. After months of learning, studying, practicing and a little bit of coloring, I made it to this point. I had originally planned to do more with it, as I tried to add more to the picture, I kind of realized that it's very rare and very difficult to add to a picture an emotion or action that you hadn't originally intended to be there from the start. At least, not once you've arrived at this point, and this is the point I was at when I tried to add more.

Anyway, I really pushed my personal limits coloring Eliana. I tried some things that I had never tried before and I feel very satisfied with the results. I also learned a lot on this one. When I started coloring this image, I thought it was going to be one of my best, and by the time I was halfway through, I decided it was crap and I could do better.

Anyway, I can see some things that I like about this image and some things that kind of bother me, but I am curious to see what others think when they see it. What looks good to you? What do you think could be improved?

Oh, and BTW. One thing I learned a little too late is Web Safe colors. In my opinion, the colors look great on my monitor. But when I look on it on my work monitor all the colors look bland and faded, and the skin looks orange. When I look at it on my wife's iPad, it looks kind of in between. Let me know how they look on your screen, I am hoping they look better on more monitors than not.

Perfectionism: A Flawed Perspective?

At the beginning of a project at work that had a pretty tight deadline, the Project Manager on the customer's side sent out an email describing the importance of avoiding feature creep. At the end he included a quote that said "Perfect is the enemy of good." I don't have time to write a post going as in depth with this subject as I would like to, but at the least maybe it will spark a discussion, or at least give everyone something to chew on.

In my career, and in my personal projects, I have been thinking a lot recently about perfection, and how inefficient it can be. I have been accused from time to time of being a perfectionist, and recently as I have been trying to increase my efficiency at work, and spreading my free time across multiple personal projects at home, I have been questioning the effectiveness of wasting time being perfect. Today, I accidentally came across this blog post which provided some definition on the abstract ideas floating around in my head on the subject. Ironically, I felt that it clarified to me that some of my least favorite flaws about myself probably come from my inability to recognize when myself or others have done a good job, or even a great job, and move on to the next task, rather then getting hung up, upset, or negative because the job isn't "perfect" by my standards.

I am not trying to vindicate shoddy work. Great work does not have to be perfect. Improvement should still always be sought for. We should always be trying for the best that we are capable of doing. But with a little extra mental effort on our part, we might be able to recognize that the best we are capable of in our social lives, career, or personal projects is not just one absolutely perfect task, but instead accomplish a lot of tasks that we perform very well.