Simply Ian...

5 Mistakes Solo Developers Often Make

simplyianm — Sat, 31 Mar 2012 21:42:03 +0000

Developers often code differently when not in a team. They deem many tools unnecessary for projects as “small” as what they’re doing. These tools are really actually pretty useful for solo projects, even necessary.

Mistake 1: Solo programmers think of version control as a publishing system.

These people write maybe 1,000 lines or more of code, then commit with a message of “pushing version 0.3″ or something like that.

First of all, the point of version control is as it says in its name — version control of your source code. It allows you to see every individual part of your code and your thought processes at the time (via commit messages, which are important too). When you make huge commits like this, you are not allowing selected changes to be rolled back.

Version control really is to manage your code’s history. It’s not just for showing off your code to the world. Commit early, and commit often. Don’t store your work on flash drives. If you lose the drive, your project is dead.

If an issue crops up, you won’t be able to roll back the specific part of code that messed everything up. Instead, you’d have to change everything manually, searching for what was wrong. This wastes time and energy and produces frustration.

Mistake 2: Solo programmers don’t write unit tests.

Programmers like this probably debug using print statements and go through the code flow. This usually happens due to laziness and/or a feeling of “I’m the only one messing with my code, so it should work the way I made it work”.

No — this is not the answer at all. Instead of wasting time doing this, how about writing individual tests for each METHOD? Compare the actual result with the expected one and make sure the code is working properly through a myriad of use cases. Furthermore, when you change something, if something breaks, you will know what broke something since your tests broke right after that commit.

This makes everything easier to see. When you don’t write unit tests, not only are you not sure if the code works, but you are wasting valuable time as your project grows debugging and making sure everything still works. An immense refactor could break one thing, but you would have to dig for hours finding what exactly broke and where.

Although, it’s easy to forget to build your project after you change something and commit it, or it takes a lot of time, which leads me to the following statement.

Mistake 3: Solo programmers don’t use continuous integration.

Continuous Integration, “CI” for short, is basically a process where your project is built from your latest source code. Whenever you modify your repository, the CI system basically builds your project, runs tests, and makes sure everything is in order.

People normally don’t use this because it seems like overkill for a simple project. Your project is small and pretty much personal. You can test it all on your own system since you’re the only one building your code. This is pretty naive. There are times where you forget to compile, or you don’t have an IDE handy and don’t see your mistakes right away.

An immediate benefit from this is that it saves time. You don’t have to manually wait to compile your code; as shown in this picture, compiling really takes out time from your programming and breaks your train of thought. Furthermore, it makes sure all builds are run in the same fashion, so that you know code will compile for everyone.

Now, maybe 2 years ago, that wasn’t really an option. You had to purchase a VPS and configure it with Jenkins or some other thing, etc. But now there’s a really nice distributed build system, a FREE one, called Travis. It supports a number of languages, from Ruby to Java to Node to Groovy — it’s constantly getting more and more support for more and more languages.

Travis also emails you when a build breaks and gets fixed, so I get a notification when I make a mistake in my code.

But CI really isn’t useful if you don’t have a nice, automated build script. This brings me to…

Mistake 4: Solo programmers don’t use build automation.

There are a whole lot of people I have seen who decide to commit their .project in Eclipse or their nbproject folder into source control, thinking that that’s all they really need to have a well-made project.

But the problem is, Eclipse users can’t use Netbeans projects and Netbeans users vice-versa. People have to work to get other people’s code working in their development environment.

That’s where build scripts come in. I am a huge fan of Apache Maven. It automatically downloads dependencies and builds your JAR in the way you want it. Best part, it’s universal. I works in all ides and text editors. Everyone just has to type “mvn clean install”. It’s that simple. And by everyone, that includes your trusty friends Jenkins and Travis, too.

By using build scripts, everyone can jump into your code right away. When alone, you can transfer code between computers easily. Furthermore, build scripts usually have other tools part of them, such as replacing variables within files such as version numbers. It really makes things a lot easier and consistent.

Mistake 5: Programmers don’t plan.

They just code. While it’s nice to be on a spree of ideas, you need to engineer your code before you write it. A few months back, I dropped a project because it was too much to maintain — the code was all just too messy and unorganized. I had random classes left and right, all because I didn’t plan the architecture. Good design is important.

Personally, I use Google Docs to manage everything. It’s a nice cloud based service that allows you to work on documents in real-time with others. A text file in a Git projects works too, but Google Docs is probably a better choice.

Conclusion

I think the reason many people don’t follow these rules is because as an independent programmer, they think they’re free to do whatever they want and handle everything on their own. The thing is, they’re not. It’s much, much better to follow the same practices as they’re not called “best practices” for nothing.

People should treat all of their projects as they do group projects — carefully planned, well-made, etc. You shouldn’t be programming in the dark. Commit your code when you write it and treat it as a quality project, not just a bunch of ideas whipped together into a bunch of code.

Feed enhanced by Better Feed from Ozh

MySQL check difference in days

simplyianm — Tue, 07 Feb 2012 02:32:50 +0000

I‘ve encountered this problem recently and here’s how I figured it out:

SELECT COUNT(*) FROM pvp_kills WHERE death_killer='Camaroow' AND DATEDIFF(CURRENT_TIMESTAMP(), death_time) <= 1;

There is no period at the end of this blog post

Feed enhanced by Better Feed from Ozh

You know you’re a geek when…

simplyianm — Sun, 08 Jan 2012 06:26:26 +0000

You know you’re a geek when…

You know Esperanto or Lojban.
You type in Dvorak (or even geekier, Colemak (or even geekier, QGMLWY)).
You prefer the Dymaxion projection for maps.
You prefer writing integers in base 16 even when not dealing with bitwise operations.
You know what Malbolge is.
You are on Github more than you are on Facebook.
You use Vim because it’s so much easier than a different text editor.
You prefer TeX over Word.
When saying “What’s Up”, you reply that up is a relative direction.
You hate Finder; “cd” and “ls” are all you need.
You find yourself saying “sudo” when things don’t go your way.
Mac < Windows < Ubuntu < Arch Linux

Things missing? I’m sure there are a lot. Comment below!

Feed enhanced by Better Feed from Ozh

Most relaxing song of all time

simplyianm — Sun, 01 Jan 2012 22:53:46 +0000

Feed enhanced by Better Feed from Ozh

Fast line segment interaction in three-space

simplyianm — Sat, 31 Dec 2011 07:07:19 +0000

I’m pretty proud of this code, seeing that I just learned the basics of linear algebra and vector math yesterday.

Click to toggle codeblock

    /**
     * Checks for a collision between two line segments.
     * RoyAwesome says rays are line segments.
     *
     *  Perhaps Roy needs to brush up on geometry then
     *
     * Code based on http://www.bryceboe.com/2006/10/23/line-segment-intersection-algorithm/
     *
     * @param a
     * @param b
     * @return
     */
    public static boolean checkCollision(Segment a, Segment b) {
        return (ccw(a.origin, b.origin, b.endpoint) != ccw(a.endpoint, b.origin, b.endpoint))
            && (ccw(b.origin, a.origin, a.endpoint) != ccw(b.endpoint, a.origin, a.endpoint));
    }
 
    /**
     * Checks if 3 points are counterclockwise.
     * (A helper for a helper method)
     * @param a
     * @param b
     * @param c
     * @return
     */
    private static boolean ccw(Vector3 a, Vector3 b, Vector3 c) {
        //This is Java lisp
        return (c.getY() - a.getY()) * (b.getX() - a.getX())
            < (b.getY() - a.getY()) * (c.getX() - a.getX())
            || (c.getY() - a.getY()) * (b.getZ() - a.getZ())
            < ((b.getY() - a.getY()) * (c.getZ() - a.getZ()));
 
    }

	/**
	 * Checks for a collision between two line segments.
	 * RoyAwesome says rays are line segments.
	 *
	 *  Perhaps Roy needs to brush up on geometry then
	 *
	 * Code based on http://www.bryceboe.com/2006/10/23/line-segment-intersection-algorithm/
	 *
	 * @param a
	 * @param b
	 * @return
	 */
	public static boolean checkCollision(Segment a, Segment b) {
		return (ccw(a.origin, b.origin, b.endpoint) != ccw(a.endpoint, b.origin, b.endpoint))
			&& (ccw(b.origin, a.origin, a.endpoint) != ccw(b.endpoint, a.origin, a.endpoint));
	}

	/**
	 * Checks if 3 points are counterclockwise.
	 * (A helper for a helper method)
	 * @param a
	 * @param b
	 * @param c
	 * @return
	 */
	private static boolean ccw(Vector3 a, Vector3 b, Vector3 c) {
		//This is Java lisp
		return (c.getY() - a.getY()) * (b.getX() - a.getX())
			< (b.getY() - a.getY()) * (c.getX() - a.getX())
			|| (c.getY() - a.getY()) * (b.getZ() - a.getZ())
			< ((b.getY() - a.getY()) * (c.getZ() - a.getZ()));

	}

As it says in the comments, I borrowed the original idea from this guy.

Feed enhanced by Better Feed from Ozh

Writing Readable Code

simplyianm — Wed, 21 Dec 2011 22:22:12 +0000

Writing readable code is something you don’t really see. After all, it’s code. Take HTML for example. Lots of strange tags to remember, formatting, and lots of trial and error. HTML/XML isn’t really the most readable thing.
(...)
Read the rest of Writing Readable Code (242 words)

Feed enhanced by Better Feed from Ozh

Why I write open-source code

simplyianm — Sun, 27 Nov 2011 01:25:38 +0000

Recently, I have joined the development team of Citizens, a widely-used server mod for Minecraft. The code for Citizens is open-source, meaning that anyone can view it, fork it, modify it, or even make money off of it. From a business standpoint, I am working for free. Why would I do this?

First off, open source code gets you followers. Future employers, other colleagues, etc. will recognize how good you are at coding by how widely distributed your code is. It shows your ability to work in a team, use Maven, etc. It’s like doing community service. No — it is community service. Doing this shows dedication.

Second, writing open source code augments my skills. I’m learning how to work with others and use the tools of the trade to make everything. I’m learning deprecation and other things you wouldn’t learn from a private project. It’s like an internship, except you’re recognized for your work.

Lastly, I use the code. Linux isn’t written by unpaid people who just have a hobby. Linux is written mostly by companies like Novell, Red Hat, IBM, and even Oracle. Other people are helping me write my code in exchange for me sharing my code. It’s a win-win situation.

Open source software isn’t about doing free work. It’s about giving back to the community

Feed enhanced by Better Feed from Ozh

On the Potential of Computational Creativity

simplyianm — Fri, 11 Nov 2011 17:38:57 +0000

In the 19th century, Ada Lovelace, the world’s first programmer, stated that computers, while they could do a lot, could never become creative. Computers, after all, were just algorithms. But today, computers have become so powerful that it seems almost inevitable that computers will become creative. In the movies, we see AI building new robots and creating better programs. But is this all just science fiction? Could we make a computer act like a human brain, creative and all?
(...)
Read the rest of On the Potential of Computational Creativity (433 words)

© simplyianm for Simply Ian..., 2011. | Permalink | No comment | Add to del.icio.us
Post tags: ai, artificial-intelligence, computational-creativity, nlp

Feed enhanced by Better Feed from Ozh

Leaves vs. Children

simplyianm — Sun, 23 Oct 2011 23:38:29 +0000

While children are the elements of the next generation of a tree, leaves are at the very end of the tree nodes. Compare it to an analogy of an oak tree. The points where the branches come off are the children, but the leaves are the individual leaves on the tree.

© simplyianm for Simply Ian..., 2011. | Permalink | No comment | Add to del.icio.us
Post tags: data structures, nlp, terminology, tree

Feed enhanced by Better Feed from Ozh

Cordelia: A command-line program to test you on your Shakespeare

simplyianm — Tue, 11 Oct 2011 02:51:55 +0000

In English class, we have an assignment to memorize a bit of a Shakespeare play. I, bored, wrote up a simple program in about an hour to test you on how well you know the individual lines of a text file. If you don’t specify a file, it defaults to the first part of the famous St. Crispen’s day speech in Henry V. Here’s a link to the Bitbucket project: https://bitbucket.org/simplyianm/cordelia. You can download cordelia-0.0.1-SNAPSHOT at that site. The program is contained within a zip file. For Windows users, double click the run.bat file. For Mac users, it’s a little trickier — navigate to the directory where the unzipped files are in Terminal and type in “sh run.sh”. For Linux, run the sh file. (I haven’t used Linux in a while so I don’t know the exact process)

© simplyianm for Simply Ian..., 2011. | Permalink | No comment | Add to del.icio.us
Post tags: bitbucket, programs, tools

Feed enhanced by Better Feed from Ozh