Wednesday, July 31, 2013

newsletters

I guess I'm a bit behind the times, but I haven't gotten around to setting up a decent RSS feed reader to get all my news from.  Instead, I decided to set up a spam email account and subscribe to a few choice newsletters instead.  I feel that getting the news on some sort of a regular basis is something that people right out of college don't always think about.  For a while I had a few sites that I would go to, but now that I'm starting my own company, I decided to try and get more targeted news.

Just to make sure that everything is nicely organized (because often times I just ignore things that are disorganized) I created a new email account just for receiving and sorting newsletters.  I've signed up for newsletters from all the major companies that I could think of that would support the technologies that I might ever work with.  This includes all the languages that are part of my products and articles about marketing, management, and other various executive type topics.

So far the results have been surprisingly good.  I've gotten to view online developer events, received developer digital magazines and browsed through a few high-level corporate articles about advertising and marketplace trends.  What I think is probably the most important aspect of the newsletter subscriptions is that I feel in some way obligated to at least browse through the emails.  I don't know about other people, but I like to feel like my inbox is under control.  And that's when I'll hopefully noticed things like security updates and bug fixes.

Tuesday, July 30, 2013

log files

Today I finally decided to venture into the world of log files.  I know, I know, it's not a very exciting portion of any program, but I'm sure as most coders have noticed at some point in their career, most to all programs have some form of logging.  This logging can be anything from simple system messages to complex server logs.  So whether you're keeping track of sent emails or logging errors with the system, logs are more common than one would think.

Yeah, not the best intro in the world.  I guess that sums up how I used to feel about log files.  But I actually reached a point in my coding where I decided that creating log files was actually necessary.  I feel that I am going to be more productive now that I have a system to log output.  It wasn't a quick process either.  I spent a long time just going through console output.  Now I have a system where my standard messages are logged to a file and my most current debug session is being sent to the console. 

The log file has both a short term and a long term solution.  I can keep track of what's happening over time with extended usage and more quickly look at specific areas that I'm trying to work with.  When writing this I still feel that I'm not actually conveying the importance that I've just created.  The ability to quickly change the debug output of large portions of code will allow me to switch between simple method debugging and complex process debugging.  Without doing this, I would have been getting in my own way.

Monday, July 29, 2013

visibility

Today I realized my mistake.  I should have just posted less yesterday.  I'm working on the exact same stuff, but now I have less to talk about.  So, when you think about it, what good did I really do by posting a bunch of stuff yesterday when I could have just copy pasted today?  Oh sure, there was still actual work done today.  Yeah, I know I could just talk about that things I'm actually doing.  Whatever.

I think today I need to talk about visibility.  This is just going to be for my own sake, because I need to think about visibility more.  Other than this blog, I currently have zero visibility.  Oh sure, I've briefly mentioned to friends and family that I write code, but that's not exactly being visible.  My problem is that being visible asks a lot of questions.  I like to solve problems.  I don't like worry about things like, how difficult is it going to be for me to compete in the marketplace.  If people hear my idea, are they going to be able to copy it?  If I go to the doctor, will they tell me that I'm actually sick?  These aren't questions that I like to ask.

Yeah, I think that I got a bit ahead of myself when I spoke to an investor.  One investor has been spoken to and I have not heard back from him.  He seemed to like my idea, then he didn't.  That's not exactly getting my ideas out there in any way.  So many questions though.  I don't have patents on my ideas, so if someone wants to/can copy me, I couldn't legally stop them.  I guess that kinda assumes that people would want to copy me though.  I wonder if that's a mistake.  I already have some vague technical notes, but those barely explain things to an expert in the field.  I haven't even tried to imagine what other people would think.  I know when I spoke to that one investor he vaguely heard what my idea was, but I did feel a bit under-prepared.  I need to go to the investor store and take some statistics.  "Investor guy, would you rather I publish, or keep researching?"

Sunday, July 28, 2013

updating and complaining

So, the code update project is turning out to be a lot more work than expected.  Yeah, I had a lot of code in place that needs major changes to keep up with my current standards.  What I didn't remember is that the project itself is fairly complex and needs to be updated when the code is changed.  This means I'm going in there and changing small parts of a dozen or more files for one set of changes.  It's not really as bad as it sounds, but at the moment I'm a bit discouraged that I still have a lot more major changes to make. 

The worst part about doing this is that I am making no new progress.  Everything will function exactly as before, and what's even worse is that I'm not even upgrading my skill set.  My motivation for this particular project is simply the fact that I will know I've coded everything I possibly can to the highest possible quality that I know how.  Sure, this might not be a realistic goal, but hopefully it is.  I know that this is better than just abandoning my older code.  I can already tell that the longer I let it just sit there, the harder mentally it's going to be to bring everything up to the current standards.

There's gonna be a bright side to this as well.  I'll know how capable I am going to be when it comes to maintaining all of the projects I've been working on.  Most people that just write code don't really think about this.  I didn't even really get it when co-workers would tell me about the difficulties of supporting past projects they've worked on.  But the mental effort that goes into switching between things that have not been worked on for any amount of time is much larger than expected.  I think that the hardest part is learning something that you already have mastered.  It's not going to help my technical abilities in any way, but it is required if I want to keep all of the projects that I have created.  I made them and own them and need to be capable of working with them if that is what is needed.  For example, the updates I have made most recently are for a project that I will combine with the previous project.  If the projects have noticeable differences in quality, that's just not going to be professional, among more obvious problems.

Saturday, July 27, 2013

updating old code

Today I am updating old code.  I've noticed that the more I code, the more I'm learning how little I know.  Yeah, that's blatantly cliche, but I'm talking about things that aren't really part of my useful scope of knowledge.  Well, not at the previous point in my career.  At some point in my life I probably would have learned these things in a more traditional way, but now I'm learning them out of necessity.  I can't have users creating usernames that accidentally crash the network.  I would like breaking my product to at least seem difficult for troublemakers, nevermind for creative people that simply typed the wrong thing into an input box. 

Really, the updates aren't even all that important.  I could have simply banned certain input.  But I think my users will appreciate having more creative options.  I know most people won't ever notice something like that, but as a new company I have to take my advantages where I can find them.  So I attract a few tech-savvy people that will notice this change.  They might mention my app to a few of their tech-savvy friends.  Now I have a few more customers than I did previously.  Yeah, that's might not even make me a lot of money, but with zero current customers, who am I to judge?

Looking at the optimistic side of this approach, the more I code, the more I'm going to learn these little things that I'll be able to implement to attract a few niche users at a time.  That's still a few more than I had before.  Not caring about these niche users is a problem I'd like to have.  But until then, I'll keep improving my quality in any way that I can.

Friday, July 26, 2013

core tests written

I like what I have completed for my testing.  I now have coverage for what I consider to be the most important and unique core functionality.  I still have plans to expand coverage to some of the more utility type functionality, although most of that will not affect the core operations of the product.  That is going to be mostly for testing for bugs and other general automation purposes. 

I also did some routine maintenance to some of the functionality that I was testing.  This isn't going to change the functionality or performance in any way, but it will make the code more pleasant to read.  These are minor changes, but I'll have to make sure that I remember to create a backup. 

I still have some code left to document that I've been meaning to get to for a while.  The part that I'm looking forward to is expanding the complexity of the existing tests.  All of the basics that I wanted to accomplish are done and now I can focus on meaningful upgrades to the core set of tests.  I think for now I have completed what I wanted to for this project and it's time to start thinking about where my energy is going to be best spent.

Thursday, July 25, 2013

my first day off

I think I'm going to call today a day off.  I called into work sick today.  That's what people would normally do when they're working in an office.  You don't have to actually be sick to take a sick day, but it does let everyone that you work with know that you will not be accomplishing anything today. 

I like this policy.  Although technically I did accomplish things today (as I used to for most of my sick days), I did not accomplish enough to actually feel proud of my work.  I woke up late, I had things that weren't work related to do, etc, etc.  What I did accomplish will go well with tomorrow's post, so I won't give too much away.  But look forward to a good post tomorrow!

Wednesday, July 24, 2013

testing

So, I'm about half way through my first round of test writing.  I'd say that I'm probably getting somewhere around 80% test coverage.  I'm not explicitly testing everything, yet.  I also haven't even attempted to get into any of the more complex situations.  What I have so far is going to be a fairly basic, yet thorough testing platform.  Being only about half way through the product, I obviously haven't gotten to all of the features I would like to have automated.  Yet, this is the point where I can see where I'm going.

I think that at some point in the future I'll probably go back for at least one more round of test writing for this particular project.  Extensive test coverage (which is what too many rounds of test writing would be) is usually for large teams that have investors and customers.  The tests are most helpful when developers have to fix customer submitted bugs often.  Tests are actually kinda useless when major changes are made to a product (although, it depends on the changes).  But, I do not have any of these things.

I see my testing as an advantage in two ways.  One, it improves the marketability of my products.  If I'm trying to sell this to someone, my automated tests can be used both as proof of my professionalism and in certain cases, an entry point into the technical details of what I am accomplishing (although, I will have to consider how open I will be with my intellectual property).  The second advantage is that it gives me hope that at some point potential employees will be impressed with what I have accomplished.  If someone if going to spend any amount of their life working for me, on my code, they are going to need to be impressed with what I have done.  I personally would not work for a company that I thought was either unprofessional or not going to be successful.

Tuesday, July 23, 2013

practice

Today the test suite was started.  I already had an outline complete with classes and method stubs, a setup, and some utility functions for bringing in test data.  But I was finally able to create some of those important changes that will basically be reproduced with some slight variations for most of the rest of the tests.  I think what was the most important thing that was accomplished was a slight performance improvement.  Nothing is finalized yet, since my overall performance based architecture is still very new, but the changes seem to be the best possible way to solve the problem, regardless of how the new architecture works out.

And yes, this does bring me back to the discussion, what if I had been practicing test driven development from the beginning?  Would I have made these errors in the first place?  I think that when starting a product from nothing, we sort of assume that the basic, "guess and check" methodology will work best since it appears that we are actually accomplishing something.  Yeah, it does work and it makes us feel good.  I probably won't stop in the immediate future, but the more I design tests that just feel awkward with the style that I've been coding, the more I want to switch to test driven development.

I think that practice is the keyword for today.  When looking at a rather small "pile of code" one can not begin to think of it as one would a corporation with hundreds or thousands of employees.  The numbers can not be compared.  All that one can actually do is to keep practicing.

Monday, July 22, 2013

GitHub

So, I added my GitHub account to this blog.  It should be on the right in the about me section.  I didn't spend any time working on it yet, so it's just some text instead of a clickabe link.  That's fine though, at the moment my GitHub is just a few coding assignments that I've gotten from jobs I've been applying to. 

The most recent company that I applied to(well, actually they contacted me and asked me to apply) asked me if I had any products posted yet.  I really don't like that.  I mean sure, it's a bit rude for me to go around asking established places to fund my business, but I've been upfront about it. Other than actually referring to myself as a "contractor" or temporary help, there's not much more that you can do other than to state you have projects you are working on, will keep working on, and plan to create income from someday. 

I think that my GitHub is going to be similar to my employment process.  The actual topics chosen for the work are exactly what one would want.  I mean, if a beginner can't figure out how to solve the problem at all, that is going to speak volumes.  But more important than judging beginners,  I think that fairly well-known, foundation type problems will give more experienced developers a chance to open up a discussion about style.  Yeah, I solved the problem you asked for, but I took a lot of shortcuts because I don't really care.  Actually, you might not like the way that my need for excessive labeling fits in with your current employees.  Maybe, these points will give us something we can actually talk about in a follow-up interview.

Yeah, I could just start giving my code away for free.  I'm sure that's how some people are going to run a business.  Although, I know many of them are going to call themselves "hobbyists".  The first company that I worked for had some of the most strict intellectual copyright rules in the world, but they allowed any and all open source development.  So, even if that were the case, I would definitely be competing with people that do not need the money.  Even if they aren't called hobbyists, there are going to be a lot of people in that space that aren't even trying to run a legitimate business.

Sunday, July 21, 2013

JUnits and Linux

So, still the weekend.  Today is avoidance day.  My next task needs to be writing JUnits, but I do not want to do that.  Writing JUnits a while after a project has been coded really helps one to learn why people use phrases like "test driven development".  Yeah, I have to go back into the code and remember exactly what does what, where everything goes, etc.  Relearning my own work isn't the easiest task to start.  But the real problem is that I can't stop thinking, would I have done this differently if I had approached it from the beginning with the mentality that tests were going to be important?  I could reorganize my code, restructure a few things, but I probably won't.  I like the way the code functions and I've already done several rounds of refactoring.  But tests are going to be more important that I had thought.

In addition to avoiding JUnits, I'm also avoiding Linux.  I know that most developers prefer to code in Linux for whatever reasons they have, but I have decided that I'm making the switch to create a separation of my company and everything else that I do.  So what, why don't I just do it?  I think it's similar to the todo lists I mentioned in yesterday's post.  I'm actually not far enough along yet to justify having a space dedicated to just being a company.  I don't have any customers.  I don't have any marketing or advertising outlets.  I don't even have any decent office supplies.  So why am I in such a hurry to make this particular change?  Yeah, it's going to be helpful to learn the operating system.  But I guess I can't convince myself that having this separation is actually going to be helpful.  I think I'll need to re-evaluate this decision after I have my first customer.

By the way, I'm not sure if anyone's noticed, but I'm also avoiding using a spell-checker.

Saturday, July 20, 2013

weekend

Today is the weekend.  I got out and did some physical exercise today.  Painting walls and cleaning windows mostly, but it was a good change of pace to be away from the computer for a while.  Outside of my exercise schedule, I don't leave the house a lot these days.  When you work in a cubicle or do other extensive professional computer work, you tend to get accustomed to a certain type of lifestyle.  Adventures outside of your routine can be quite interesting.  All and all, it was a good time though.

My thought work is orginization.  I have a system in place.  My current system includes text files labeled with todo and a very vague system for keeping track of tasks.  It closely resembles more professional approaches like BugZilla and other enterprise solutions.  But, the system is mostly for show at the moment.  Most of the volume of work occurs with new products and features.  These are always left out of the todo system because it allows you to go more quickly in the beginning.  Well, that's the theory anyway.  Yet the way things always work out, you plan all the parts of what you're going to do before you do them, it just may not be written down on paper.  I think I do this because I hate changing my plans.  Expecially plans I've worked so hard to design.  It's like yelling at myself.

So, I'll code and code and code.  Then, I have a large amount of functionality and layouts and very little direction to where the project needs to be headed.  So, as soon as I get distracted, I have to "get back into" the project.  I think that if I just keep trying to stay organized, it will even out my productive bursts.  When I run out of ideas, or get stuck on a problem, I'll have a list of shorter tasks that I can accomplish to feel good about myself again.  Then, I'll have a list of completed tasks for patting myself on the back later.  It sounds like a good system, but I still need to stay current.

Friday, July 19, 2013

thought work

Today was a thought day.  I spent the day contemplating the direction of my company.  One of the more important ideas was the ability for me to expand in terms of employees.  If new hires can not or do not want to read my code, I am going to have a difficult time convincing people that working for me will be worth their time.  Going over the data_discussion documents (which is part of the genetics project in the science sector) was well worth my time.  For starters, it outlines what exactly my technical advantages are and how I will be able to communicate those advantages to the scientific community which will be knowledgeable in biology, physics, calculus, etc, but may not be as knowledgeable in certain aspects of computers.  This could be the most important part of that area, because if a customer does not understand why they would buy a product, they will not buy that product.

Other thoughts included my rate of development, how that effects my overall ability to maintain my organizational system and company reputation.  The rate of development is something I often forget because one usually thinks, the more accomplished the better.  I feel that sometimes if a developer is not careful, they can sacrifice the smaller details to expand functionality.  This has both advantages and disadvantages, but today I was focused specifically on how that effects my ability as one person to stay organized.  If I keep developing for the sake of writing code, I'm going to end up with a big "pile-o-code" instead of an efficient system that's going to be around for a long time.  I know that everything that I do will have to be viewed and probably worked with by another person at some point.  There are the obvious points that will get skimmed over, documentation, organizational charts, code reuse, and code readability.  But currently I'm still just one person that has to maintain all code by myself.  This means that when I switch from one part to another, I have to remember, or more often, relearn what I was doing at the time.  I also have to remember to keep all parts of my code current with the standards and techniques I'm working with at the moment.  Sometimes that's a bigger deal that other times to apply a new coding standard to old sections that may have complex dependencies or parts that were "good enough" at the time. 

Finally, I went over how my company reputation is going to be significant going forward.  This means that everything that I code is going to be a part of my company.  This won't seem like a big deal most of the time, but some people are going to think, why is a research lab wasting it's time making computer games?  Why would we fund a social app that's not going to be around for very long?  And of course, how does my smallness hinder me in my ability to move forward?

intro

I am a computer science major.  I first learned HTML in middle school and hardware freshman year of high school.  I learned Java and everything else in college.  About two years ago I decided to start my own software company.  Since then, I have been developing apps that fall under three general categories.  1. Science applications 2. Security/Enterprise applications 3. Social applications.  Each one of these categories has many different products.

1. Science applications - This category started with my senior project in college and has entries in significant directions in the field.  Products include genetic research and artificial intelligence research (and no, game ai and other forms of automation are not included in this discussion, although I also do that).  This area is going to be the most difficult for me to pursue since there are very limited customers in the field, practical applications are very expensive (labs, custom hardware, data, etc) and marketability is extremely hard to prove.

2. Security applications - This category was initially a bit of a joke, although it has become more of a center to my overall company strategy.  The idea is basically to help companies protect data through a variety of different means.  This can mean anything from actually physically guarding data with an application to simply making better products that companies will be able to trust more than their previous applications.  There are also some products that don't exactly fall under the "security" label, but under the "enterprise" label.  That simply means that the product I am making is not going to be just for one person to use, but an entire company.  The idea that products in this category aren't made for people is what this is about.

3. Social applications - This category is for applications that will be used by anyone.  The products may or may not cost money.  Ads will probably support most of the products in this category, where both other categories will require payment.  Products in this category could cost money, but at the moment that seems like it would hinder the ability to spread and gain popularity.  Social applications also includes games that are both multiplayer and single player vs. computer ai.

At the moment this is the state of my company.  The specifics are probably going to change over time, some of the security apps might become social apps, some of the social apps might become security apps, and I've even thought about a gaming category, although that seems a bit too ambitious for me.  I am not even close to the mainstream "gaming" genre, so most of what I have falls under the social aspect of the internet.  I think that as an up and coming company, it is most important to understand where I am currently standing and what that means to me going forward.  If I can barely do write a simple 2D animation engine, I don't want to think about writing a 3d engine.  The same applies to all of my other applications.  I am just starting my company and there are those out there that have been in this industry for years longer than me.

I hope that you enjoy my blog.  Look for future company updates(assuming I remember) that will re-evaluate what direction my company is going.