Enabling Remote Desktop Remotely

I found this page on how to enable remote desktop remotely, and found the tip handy enough to pass along.

Too bad it won’t work if access to the registry via the network has been disabled :-/

Computer Science Freshmen

As our legions of students head back to school, I got to thinking about how my educational experience has changed with each passing year, and the things I wish I had been told before starting. Not much of it may apply to non-CS majors, but software engineering students may find something of use. And if you aren’t a CS or SE major? Read this post anyway so you can be there for your CS buddies! With no more buffer, here is the list:

1. You are going to want to quit. I don’t care how proficient you are in programming, you are going to hit a snag or two in your first quarter or semester. Something won’t compile right, you are getting exceptions for weird reasons, an algorithm is returning odd values – it is going to happen. It gets frustrating. What I wish someone would have told me is that it is happening to everyone. Work through the problems (better yet, find a mentor to walk through them with you), and stick with it. The ability to write whatever you want for whatever reason is coming soon, and I have to say that if you really enjoy computing, being a programmer is one of the best professions you can have.
2. It gets easier! Programming courses are difficult for a lot of people, more so for those without a lot of a background in the field. You are going to have to learn everything from the syntax of the language to your development environment’s method of finding libraries. These problems fade very quickly – you’ll be amazed at your ability to retain the solutions to these annoying problems.
3. Don’t be cocky. One thing I hated my freshman year was the number of people coming in thinking they knew everything. It gets even more amusing when you meet incoming freshman who think this after you’ve matured a year or two. So listen: you may be the best computer person at your high school, and I’m sure your family thinks you are the next Bill Gates. However, there are millions of people that know more than you, and you are going to meet a lot of them in a very short amount of time. Go to school to learn, and listen to whoever will talk to you about whatever. You’ll be amazed with how much you have to offer, but more importantly, how much you have to learn.
4. Don’t fear the supposedly smart kids. In my CS classes, we always had a couple of those cocky kids I mentioned above. These people may be knowledgeable, but that does not mean you shouldn’t ask a queston out of fear of their reaction. If it is an honest question and someone in the class scoffs like “psh, EVERYONE knows that,” ignore it. It means they just learned something they didn’t have the courage to ask. I’m not kidding, take note of who those people are, and keep asking questions. After you finish your first year strike up a conversation with them. You’ll be surprised at how less intimidating they seem when you find out how little they’ve progressed.
5. Use your professors! They are amazing mentors, and will walk you through assignments providing whatever help they can. In class they’ll teach you languages, design patterns, data structures, and algorithms. In private, they’ll teach you how to code. Super student initiative bonus: use other CS professors teaching the same class for a different approach. Most professors really (really!) don’t care if you go to someone else for help. They just want to see you succeed.
6. Find something to do away from your computer. You are going to be spending a lot of time at your machine, increasing over time, writing and debugging code for classes. If your hobby is gaming, your eyes are going to hate you, your wrists are going to suffer, and you will start to get headaches. Step away from your computer, whether it be to do math homework or hang out with your friends. Just get away for an hour or two – it will help you in the long run.
7. Take up small coding projects on your own. The only way to get better at coding is to code, code, code. Taking up your own projects will solidify and expand upon what you’ve learned in class. The quickest way to becoming a competent programmer is to find something you want to work on it, and work on it. If it is in another language or involves a technology you’ve never worked with, so much the better. You’ll be surprised how much your knowledge carries over.
8. Energy drinks will keep you awake, but they will not help you code. Your body needs sleep, don’t fool yourself into thinking the code you write at 4:00am is going to be usable tomorrow. I’m completely serious about this. If you need sleep, sleep.

To my readers: that is all I can think of. Any other tips? Leave them in the comments!

Geek Adventures: Project Management – Implementation

Last time, I talked about the requirements and initial division of an attendance database project for Computer Science House. If you recall, we left off with the project having been split into parts that will eventually be coupled into a complete system – these parts being an iButton interface, iButton back end, user interface, and client back end.

Mark, having been on the last team’s attempt to create this database, was tasked with getting our preliminary idea of what the database should look like up and running. Additionally, since he’ll be working directly with the database, I’ve assigned him the task of creating a PHP interface for interacting with the database. This interface will be called from the user interface as a means of centralizing the database calls for easier updates and maintenance.

Dave offered his help with whatever module needed developing, so he is primarily responsible with developing the user interface. He’ll be using PHP, JavaScript, and CSS as his development tools, utilizing Ajax-ian techniques for creating an interactive interface. This is going to be the most time consuming part of the project, so while Dave is responsible for the primary design and page layout, both Mark and I will be jumping on board to implement specific features when our parts are complete.

As for myself, being the only one with the iButton hardware for now, I am implementing the iButton interface and back end. The technologies I am using are Java, JavaScript, and LiveConnect. Java allows for the development of both the iButton communication application (the iButton interface) and the applet (iButton back end), the first of which was necessary to use the iButton Java SDK, and the second of which allows us to use LiveConnect to make the iButton IDs available to our web user interface invisibly.

The division of the project into smaller parts allows each member of our team to develop in parallel. With an emphasis placed on clean, self-explanatory interfaces existing at the points in which the modules come together, core development should proceed smoothly. As a bonus, each member is granted the freedom to develop in their own style at their own speed, with the only required communication occurring when it is time for members to link up their pieces.

For now, we code. See you when it comes time to integrate!

Slow Read of Socket Input Streams

I ran across a problem where I had incoming socket streams taking a really long time (25-65 seconds) to read from. I knew the data was leaving the client application, and the incoming connection socket handling code was running correctly, so the only thing holding up my server handling the data was the speed at which that data was being read from the socket. Additionally, this was all running on a local loopback so network latency wasn’t the issue.

The solution was simple: while I was manually flushing the socket OutputStream on the client side, I had forgotten to close the socket explicitly (which forcefully flushes the socket’s streams before closing). Once this modification was made to the client, the data appeared instantaneously on the server.

So when doing I/O, don’t forget! Flush and close your streams and sockets!

Geek Trap: Your Body and How to Abuse It

If you are a geek, you probably find that your hands are on your list of top 5 favorite body parts. And they should be! They allow you to code, solder, and… well, hands do a lot. Unfortunately those highly valued appendages aren’t indestructible, and after spending a large amount of time at a keyboard they will deteriorate. That is right: I’m talking about repetitive strain injuries, or RSIs.

I’ve gone through it: wrist pain, tingly fingers, and joint aches caused by long hours at the keyboard for work and pleasure. You can find many pages on the subject, but none of them say what I have discovered about the condition.

It sucks.

The sites on RSI all tell you not to work through the pain, but to address the pain and take steps to remedy it as soon as possible. That might work if I weren’t a young male with a mild case of a testosterone induced invincibility complex. I initially tried to just keep clacking away on the keyboard, not wanting to forfeit time at home on my individual projects, and not wanting to be unproductive at work. It was a bad idea. I reached the point where I had a constant pain in my wrist and a tingling sensation in my thumb. It probably would have gone away if I had eased off for a bit to heal.

Those well informed sites will also tell you to take breaks regularly to give your body a break. I had always thought of taking breaks as a sign of weakness (thanks RIT!), so I dutifully ignored the suggestion. What I learned when I did start to take breaks was that our academic institutions were hiding that breaks can be fun. I’ve learned that if you plan your work around your breaks, about one 10-15 minute break every 90-120 minutes depending on how well you are concentrating on a particular day, you can increase productivity. This time range blocks your time into ‘productivity pockets’ (my term, don’t steal it) that are highly recommended by concentration ninjas. So just as I start to feel the productivity decline of mental exhaustion, I go bother a co-worker or refill my coffee cup – sometimes both. My hands appreciate it, my brain re-energizes, and I hit my next productivity pocket (seriously, that phrase is my invention) I’m refreshed and ready to go.

And as far as “exercise” goes, it really does help. I tried a couple things, like holding my palms outstretched and trying to push down and then up on a horizontal surface. I looked kind of silly. I instead recommend what I feel has really made the greatest difference in healing my RSI: power putty. I’m not product placing or anything, the stuff works for a couple reasons. First, it gives you something dynamic to do with your hands. Squeezing those metal spring-resistance devices might work, but they bore me nearly to nap time. Squeezing a putty gives your hand something to do that you can’t really predict, so it doesn’t get old. Second and more importantly: it doesn’t look stupid while you do it at your desk. This greatly increases the odds that I’ll actually use it. And I guess third, it comes in a container shaped like a little fist, which could be used as a symbol of a political uprising or revolution, whichever comes first.

Finding iButton Adapters Quickly

The attendance database project I’ve recently written about requires the use of iButtons for verifying the physical presence of members at meetings. Having never worked with either the hardware other than as a user of it nor the software SDK in any capacity, it was a learning experience. One thing I quickly ran across when developing the software to locate a plugged-in adapter and read the iButton’s ID was the incredible amount of time it took to enumerate through the available ports just to find a connected adapter. The SDK provided examples on how to go about locating connected adapters, but to improve the speed at which it runs we can take advantage of what we know about the system and exploiting the code’s error conditions.

During installation of the 1-Wire drivers needed to communicate with iButton adapters, you have the option of selecting a default port to which the adapter will be connected. This information is stored as a property the SDK knows how to locate. The first step to increasing the speed of locating an adapter is to use this information – simply check the default port before searching all other ports on the machine. Odds are higher that the adapter is located on that port than any other port on the system, and by placing it as the first check before serially searching all other ports you increase your chances of getting on the first attempt.

The second enhancement requires a bit of background information. The example provided in the SDK shows you how to search all possible adapter types, then all possible ports for that adapter, and print them out. To be useful we would want instead of printing out the adapter and port names to attempt retrieving the device connected there. This would logically be done using the static getAdapter(String adapterName, String portName) method of the DSPortAdapter class. However, the time this method takes to return whether the adapter exists could be measured in seconds. To make this faster using our understanding of the system, we could skip over adapters we know we won’t be using (network adapters, parallel adapters, serial adapters, etc) and avoid scanning for them over all ports entirely. Reducing the size of the problem reduces the time it takes to come to a solution.

That is not all we can do, however. For some reason, if you try to retrieve an adapter using the getAdapter method and attempt to tell if it is successful by comparing the return object against null, it takes a long time. In comparison, the method throws an exception if it cannot locate the adapter much more quickly. Using this last bit of information, by putting a continue statement in your exception catching code you can just skip the attempt to open the obviously unavailable reader and enjoy a nice speed boost.

Here is some example code illustrating what I’ve talked about, excluding rolling over adapters we don’t care about. The speed of this is much faster than my first attempt, from taking around five minutes to locate an adapter to around 30 seconds. Base of code taken from the examples provided in the 1-Wire Java API. Sorry about the indenting, I gave up trying to figure out how to adjust the tabstop!

/**
 * Locate a reader to communicate with.
 *
 * @return boolean - true if adapter was found, false otherwise.
 */
public boolean locateAdapter( ) {
	boolean found = false;
	while( !found ) {
		try {
			DSPortAdapter adapter = OneWireAccessProvider.getDefaultAdapter();
			System.out.println(”Adapter ” + adapter.getAdapterName() +
						” found on port ” + adapter.getPortName());
			this.adapter = adapter;
			this.port = adapter.getPortName();
			found = true;
		} catch(Exception e) {
			System.out.println(”Adapter not found on default port, trying all ” +
					“available to the system…”);
		}
		if( !found ) {
			DSPortAdapter adapter;
			String port;
			// get the adapters
			for (Enumeration adapter_enum = (Enumeration) OneWireAccessProvider.enumerateAllAdapters();
				adapter_enum.hasMoreElements(); )
			{
				adapter = ( DSPortAdapter ) adapter_enum.nextElement();
				System.out.println(”Trying adapter ” + adapter.getAdapterName() );
				// get the ports
				for (Enumeration port_enum = adapter.getPortNames();
					port_enum.hasMoreElements(); )
				{
					port = ( String ) port_enum.nextElement();
					System.out.println(”trying port ” + port );
					try {
						OneWireAccessProvider.getAdapter(adapter.getAdapterName(), port);
						this.adapter = adapter;
						this.port = port;
						found = true;
					} catch( OneWireException owe ) {
						// Just continue…
						continue;
					}
				}
				if( found ) {
					break;
				}
			}
		} 

		if( found ) {
			System.out.println(”Adapter found! Using ” + this.adapter.getAdapterName() +
					” on port ” + this.port );
		} else {
			// Wait 5 seconds before trying again
			try {
				Thread.sleep( 5000 );
			} catch (InterruptedException ie ) {}
		}
	} 

	return found;
}

Geek Adventures: Project Management – Requirements

In my short career as a software developer, I’ve gained experience in multiple programming languages, development styles, and team roles. One role I have yet to play however is project manager. Transforming an idea into an end product using several stages of development with multiple people using many necessarily distinct technologies has always intrigued me (and here is my first public announcement-) an ideal job. Since there is no room for me to gain experience in this arena at my current job, I’ve decided to take on a small project and recruit two others to help me mature the concept and realization of a meeting attendance database for Computer Science House (CSH).

The basic idea of the attendance database falls in CSH’s need to record when members attend committe and general house meetings so we may conduct evaluations of our members. It is a simple idea until the requirements are analyzed. They are as listed:

1. The system must be able to store and retrieve which members were present at a specific meeting.
2. The database will be on a central server, but the client must be multi-platform and portable.
3. The system must be able to able to verify on some level that a member was physically present at a meeting.
4. Corrections to the database shall only be made by the executive board member presiding over the meeting.

And once these basic requirements are met, features will include:

1. The system must be accessible in the absence of an Internet connection.
2. The system will make the job of the executive board members easier by not requiring their involvement in recording a member’s presence at the meeting.
3. The system will include functionality for the evaluations director and chairman to generate reports of meeting attendance for all members to aid in quarterly evaluations.

Once equipped with the requirements and feature requests, I set out to find a couple of intelligent members that could aid in designing and development of the project. They are David Brenner (chairman, spring quarter ‘07) and Mark Schillaci (evaluations director, ‘07-’08). Dave learns as naturally and relentlessly as his heart beats and is capable of grasping abstract concepts easily. This makes him great for picking something up and applying it quickly. Mark is less experienced than Dave or I, but is also sharp. The reason I asked him to be a part of this project has two factors. First, he was on the last attempt to create the attendance database, and second, because he isn’t afraid to dream. This second factor paired with his lack of fear of being wrong yields great ideas that, when grounded and refined, become solid and actionable contributions.

With a team assembled, analysis of the requirements and how to move them into implementable items began. The first step was a separation of the system into components: the database and the client. Following this, an analysis of the components was made in order to fit the requirements. The database being hosted centrally is a given, so it really doesn’t need further discussion. The client requirements state that it must be portable and multi-platform, and obviously must be able to communicate with a database remotely. Additionally, it should be able to verify the physical presence of a member. This one is more interesting.

When developing for multiple platforms, the most efficient way to proceed is to create something that has a single interface for all platforms and a codebase that requires little or no modification to make available to other platforms. This results in creating a single user experience regardless of their operating system, and most importantly as a developer, an easy to maintain system. These objectives are most easily achieved with a web application, where any user with access to a graphical web browser that supports javascript will be able to use our application.

 The issue of verification on the client required more thought, and came to me while I was working on another project. The first method proposed by the developers of a previous attempt at creating the attendance database was to have the executive board member or house secretary log in, then manually type in or check off the names of people who were present. This system is flawed – it relies on the individual entering the information to see each member, which in a crowded room with members sitting behind couches can be unreliable. It also leaves the members not knowing if the person taking attendance noticed them, resulting in their asking “did you get me?” Immediate feedback to the member is necessary to prevent this. My solution to this problem is to use iButtons.

iButtons are a technology that in their most simple form are capable of carrying a guaranteed unique 64 bit ID. We already use them on CSH in our Drink projects Big Drink and Little Drink, as well as in prototype implementations of our iButton doorlocks, so the technology is not foreign to our members as an identifying token. In our case, a USB iButton reader would be connected to the laptop from which the attendance database client was running, and members upon entering the meeting place would click their iButton into the reader which would then record their attendance at the meeting. This solves the requirement of ensuring a member is physically present at the meeting and easily addresses the feature requesting that little involvement from the executive board member be had in recording attendance.

 The final subdivison of the client ends up looking like this with the above taken into consideration: the user interface (graphical interface), client backend (database communications,) iButton interface (physical reader and accompanying software), and iButton backend (local communications with client). In the next part of this series, we’ll discuss the technologies involved, the solutions decided upon, and the initial roadmap of development.

Reform in Education

If only educators were required to see this (~20 minute) TED presentation before being given the minds of our students. Sir Ken Robinson focuses on creativity in the arts throughout this talk, but any programmer knows the benefit of being able to think creatively when writing code.

Sir Ken Robinson – Do Schools Kill Creativity? (via TED)

http://www.ted.com/talks/view/id/66

Victory

After solving one of those “cascading problems,” the ones that seem to spawn three bugs for every one you squash, I can finally say my latest feature has been integrated in our project at work. Tag it, deploy it to the customer, *feel good.*

Some days it just feels good to get a win.

Student Perks

Being a student has many perks, but the one I’ve discovered most recently is obtaining samples from semiconductor manufacturers. I’ve started a couple of electronics projects (details to follow?), and Texas Instruments, National Semiconductor, and Maxim-IC have all provided free samples of some of the required components. This in itself is appreciated, but not entirely special because anyone can get a free sample. What made me really happy is that by using my school e-mail address, they even pay for the shipping.

How cool is that? That is the kind of spirit toward students that companies in more fields need. A small hit to profits to further a student’s education. I’m very pleased :)