Archive for the 'Software Engineering' Category
A lot of developeres I knew back in college loved using Macs for their development machines, and you don’t have to look very far to see this opinion reflected on the Internet. In total, I’ve been using a Mac as a development machine for about five months. And now that I have a spare moment to write, I want to share my experience coming from using Debian Linux as a development machine to coding Java on a Mac.
The Environment
OSX as an environment is just different initially. Using the Apple key instead of the control key is odd to get used to, so there was some loss of productivity (and a lot of frustration) when my muscle-memory keyboard shortcuts weren’t working. I got over the change after a couple weeks, but it still is a pain. The placement of the Apple key is two keys further in than control, and I now have to move my hand a decent amount to hit my very frequently keyboard shortcuts.
The windowing system also takes some getting used to. Close and application and it doesn’t actually close? What gives? I haven’t found a single instance where that has been a useful feature to have. It just adds a separate action to closing a process.
On those lines, windows can only be resized from the bottom right corner. If you want to expand something by grabbing an edge, or making something bigger by dragging an upper edge, you can’t. After growing up on Windows and then Debian with KDE, the instinctual grab and drag resulting in a non-action is annoying. The borders are there, but they aren’t functionally doing anything other than separating the window from other windows.
OSX is also missing virtual desktops. From a developer’s standpoint, all I can do is issue a giant WTF. Having separate desktops allows for the separation of distracting tasks and productive tasks. Having e-mail, instant messenger, and iTunes sharing a space with Eclipse, documentation, and my xterms (more on that in a sec) is extremely counter-productive. The argument can always be made that only applications you are using should be open, but switching workflows should be as simple as hitting a shortcut – not by manually managing windows.
A very minor point is that OSX does not feel snappy. My machine is a couple years old, so that could have something to do with it – but having a few xterms open and eclipse in the background should not cause a noticeable delay when switching to and typing into a new text field.
The Tools
The biggest thing that initially irked me about OSX was its lack of several very common tools. For example, OSX offers curl as a web retrieval tool instead of wget, claiming they are functionally equivalent. They absolutely are not. Wget has a mirroring feature that I found myself sorely missing when trying to pull down a multi-leveled source tree without version control from a web page.
Also missing isn’t as much of a tool, but a feature that is completely missing: the /proc filesystem. On a Linux box, a /proc filesystem can be easily enabled (if it isn’t by default) which contains information about the kernel, processes, devices, the processor, and a HUGE amount of infromation that comes in pretty handy in unexpected ways while developing. Not having this resource available causes headaches at inopportune times.
Other tools are available, but modified. Tools such as netstat show different information and have slightly modified options than the Debian counterparts. The result: figuring out how to display which process was tied to a port took nearly 15 minutes to figure out instead of taking a couple seconds to issue a command. Another example is top: processes can’t be listed as trees in the OSX version of the tool. It is small subtleties such as this that interrupt me when I am deep in a mental debugging stack – subtleties that kill productivity and add frustration.
A smaller issue was the lack of X11 and xterm. Console is fine for small tasks, but lacks the power and customizability of an xterm. Plus, I don’t want to reconfigure a console to match my xterm. I just want to pull over my .Xdefaults and have things the way I had them before. Luckily, Apple provides X11 in their developer pack, so installation wasn’t an issue.
Installation and Package Management
Application installation on a Mac is incredibly easy for user applications. Things like Omnigraffle (my very favorite diagramming software EVER) install with a drag and drop from a disk image to the applications folder.
However, installing common Unix tools (like wget, for reasons mentioned above) was a problem completely ignored by Apple. There is no package manager that comes with OSX by default for these kind of tools, and compilation is left up to the user. As a developer, this matters to me. In Debian, the power of the APT package management system made installing a new tool a single command process. Apple very easily loses here in terms of ease of use.
Libraries are also managed in a way that was initially odd. OSX considers applications like Java to be a framework, so access to something like JAVA_HOME is hidden behind a symlink. Not being in a standard location was initially annoying (/usr/lib or something similar), but once found, I was already a huge fan of the system. Keeping a symlink to a library is a Good Thing ™, because upgrades can be made seamlessly to new versions without requiring any updates to the shortcuts that point to the library. However, it could be done better. Debian uses an ‘alternatives’ system for all major libraries. Now multiple versions of any library can be set as the system-wide default at any time without requiring shortcut updates by allowing the alternatives system to manage the symlinks for you. This actually becomes useful in java development for allowing your application to be easily tested using different virtual machine implementations.
Conclusion
The conclusion shouldn’t come as any surprise to anyone: I hate developing on a Mac. I do no Mac-specific development, so the ease of writing Cocoa applications with Xcode means nothing to me. The features that I have come to rely on are either missing or implemented differently on OSX, leaving me with hurdles and interruptions where I absolutely do not need them.
When I am developing, I want things to just work – and I mean that from a developer’s perspective. My user experience matters less to me than having my platform enable my development productvity, and in this department OSX fails. I eagerly await the time when I can switch back to a Debian Linux workstation for my professional development, with fluid workflows and familiar tools to fuel my debugging speed and code output.
In response to my last post on Women in IT, a reader took the time to share with me her own experiences regarding women in male dominated fields. Her opinions complement the thoughts of my previous interviewee’s, and in the interest of forming a more fair and holistic view of this huge issue, I requested permission to share what she had to say here. While she has asked not be identified fully by name, I still wish to grant credit for the content of this post to Pamela M – she is the sole author of the content below, and it is very much worth taking the time to read.
As a woman studying the sciences and engineering, I was constantly made aware of my gender. My experiences in that regard certainly weren’t uniformly negative, but if I’d had to do over again, I’d have chosen a different field of study and save myself the experience of becoming an almost-but-never-quite-equal student.
Perhaps the most troubling aspect of education for female students at the institution I attended was the frequency with which a female student was simply addressed differently in the classroom than a male student would have been. I remember one gentleman in particular who would address questions from male students from the front of the room, but who would walk over and sit down for a chat nearly every time one of the female students had a question, so as to make sure that she received the personal attention she needed to resolve the issue. Multiple male faculty members would always call on the women first when trying to encourage classroom participation or never fail to praise each one for a clever answer. One faculty member would often mistakenly assume that any female student would remain ahead of the curve through nonstop hard work and he would look genuinely surprised when he encountered a female student hadn’t read ahead or wasn’t familiar with a topic from an upcoming segment.
These behaviors, while relatively complimentary in nature – assuming that a female student was most likely a competent and diligent student as well as exhibiting a true desire to make sure that female students in particular were encouraged to succeed – failed to take into account the desire of many female students simply to be taught and assessed in the same fashion as a male student. It wasn’t fair to either set of students to single out the women.
Other differences in classroom behavior on the part of a faculty member were less forgivable: failure to meet a female student’s eyes, speaking down to them, making assumptions about a female student’s predilection toward the arts and language rather than mathematics and logic, or even an increased tendency to behave as though his time was being wasted when a female student asked a question, whereas a similar question posed by a male student would be taken in stride. Of course, sometimes it was obvious that male faculty and male students expected the female students to be less intelligent than the male students, and more than once I witnessed a female faculty member obviously sharing that view (whether from her own experience or in reaction to the female recruitment drives ostensibly allowing less intelligent women to enroll, I couldn’t say). The most personally irritating thing to me was when a male professor, usually older, would speak to a mixed group of students and somehow only include the male team members in his address. It’s the opposite of what happens when you walk into a into a housewares department with your spouse and somehow, despite addressing the both of you consistently, it’s crystal-clear that the salesperson is speaking only to the woman!
I experienced less of a feeling of competition with other women than did the subject of your previous post, but I definitely saw flocks of young men crowding around female students. While somewhat flattering, at best it can make a woman dependent on having the answers available without learning to identify the resources available to her from an academic standpoint. At worst it’s downright insulting and offensive to the woman to assume that she needs the help (or company) any more than a male student would. It can be hard to discourage the more enthusiastic young men without causing offense, especially when they believe they’re being helpful and are simply attempting to be a good friend. When there are far fewer women than men around, it’s important for the male students to recognize that a female student may simply want to study and complete her classes without a lot of social activity, or that she may prefer the company of other women socially.
I do agree that some of our female faculty members were surprisingly less than impressive, considering others among our female faculty were among the best in the world. It generally tended to be the younger faculty members that were not up to snuff, most likely due to frantic attempts at recruitment on short notice, and it was easy to suspect that many of them gained tenure only due to a dearth of qualified female applicants. Their shortcomings weren’t helped by their male colleagues tending to correct them or speak down to them, even in front of the students, a practice which can intimidate some of the more intelligent women who would otherwise wish to continue on in their fields. A mentor of mine assured me that this practice can continue even into the highest reaches of academia: despite being head of one of the larger faculty committees and having been tenured nearly since the inception of her department, she still received “helpful advice” from her male colleagues and juniors, though never from other female faculty. Another female faculty member once discussed the fact that she’d often been told that she comes off as very strict and never smiled or praised a student in class. Only for a female professor would “not being sweet enough” show up on a performance review! A professor might be instructed to work on his approachability if it were genuinely interfering with students learning, but “smile more” is simply not an acceptable goal on which to base the salary of a long-established academic who is widely-regarded as one of the best instructors (not researchers, but instructors!) in her field.
I belonged to a women’s association on our campus and we used to speak a lot about the difference between wanting to be accepted as one of the guys and wanting to be allowed to retain some of our trained “female” characteristics in education and the workplace, and how a classroom or work setting generally tends to encourage one or the other but only rarely both. It’s important to recognize that, just like male students have different personalities and priorities, female students are individuals and will want different things from their educations and behave differently from each other in an academic setting. We’ve been trying to accommodate the “female” perspective for decades, and while it’s great that schools and teachers try to adjust their teaching to include different types of people and personalities, it’s important to recognize that those differences aren’t coupled to gender!
With any new female student, it’s impossible to say how hard it was for her to get to that point. She might have had an entire life of happy educational equality and be thoroughly confident in her abilities and consider her gender completely irrelevant to her education, or she might have had parents who disapproved of her choice of career and teachers who spoke down to her or graded her unfairly or any number of other things. Even if every single man attending the school at one time is a great, thoughtful, socially-savvy wonder of a human being, a woman’s experiences don’t start at the beginning of college! We’re taught all our lives about how women were for so long considered incapable of technical employment and not all of us want to feel like we’re individually responsible for proving all those past generations wrong. We read articles about how underrepresented women are in the sciences and technology, and some of us keep one eye open to see if we can figure out why. Even looking around a classroom and seeing few other women can be discouraging. For every woman who simply was more interested in studying a different subject than pursuing her interest in science or technology, how many others might really have wanted to be there and were simply discouraged or redirected or made to believe they weren’t good enough?
I think in the future it will be better. I think that women will be told more about the accomplishments of all people instead of just great women of the past, and gender will no longer really be forefront in our minds as we make our career choices. I think that interacting online with no one aware of their gender or judging them by their appearances has already helped younger women understand their capabilities. We need girls to learn well the difference between criticism actually based on their abilities and baseless criticism due to their sex and the stupidity of other children. We need to stop acting surprised when a girl shows a fledgling interest in science and technology so she doesn’t go into it feeling like she’ll have something to prove.
I think that as conditions continue to improve, more of the top tier of really intelligent women will stop saying “I’m not stupid; I could enter a different area of study instead and have a perfectly respectable and intellectually-fulfilling career without constantly questioning my own abilities and dealing with a male-dominated field, so why would I want to enter science or engineering or IT?” Women had easier in-roads into some of the more liberal arts-related fields because it was widely believed that they had at more of an aptitude for these subjects. If we consistently recognize that affinity and aptitude vary wildly from person to person regardless of gender and that women as a group are just as good at science and IT as are men, eventually these last few walls will fall.
The most important thing to remember is that at some point we started calling most of the gender education problems fixed, and they’re really not. A number of lucky women never encounter sexism directly in the classroom or workplace, and that’s a great start. But I can tell you from my own experience in college that I encountered far more sexism than I ever expected to see among such otherwise intelligent people, both for and against women. It’s easy to dismiss each occurrence as a one-time event, but it becomes harder to do when you realize how many times a particular thing has happened ‘only once’! Many of the remaining issues faced by a female student in a male-dominated field are going to be easily overlooked by others – a look on a teacher’s face, an assumption made without cause, a group of all the women paired together ‘randomly’, an independent study idea denied for no good reason, suggesting the woman do the note-taking in a group project – these still occur with regularity, even if you don’t notice it, and it’s amazing the more severe problems that can be equally ignored. Many women keep silent and try not to draw attention to ourselves because it’s easiest to blend in and let the minor things slide after years of practice, but others are going to demand fair treatment and call people on it when they’re being treated differently in the classroom, consciously or not, and it’s important to continue to listen and adapt.
Eventually those enrollment numbers will even out. If schools paid more attention to ensuring fair and equitable gender-blind treatment and made college a more pleasant place for women to mix into rather than press-ganging them into technical careers to meet enrollment quotas (leaving some to wonder whether they were actually entirely qualified), it might be less of a transition … but given some time and good parenting and teaching, eventually it won’t even occur to young women that they should have any reason *not* to become a scientist or technical professional! I think that’s a worthy goal to work toward, rather than artificially enticing all remotely-qualified women toward programs using money and special programs and opportunities. Perhaps more emphasis should be placed on retaining women in a field through the college years and into the career itself, when many women throw up their hands and leave to find something new. Women having uniformly good experiences in technical education will encourage more women to enter the same programs; all it takes is time.
Thanks again Pamela!
Rochester Institute of Technology has been supporting programs to encourage enrollment of women in their technical fields. The reason for this is painfully obvious if you happen to be studying computer science (like I am) – I think I had four women total in my nine or so CS classes this year, out of 150 or more men.
I always had assumptions of what it was like to be a woman in a technical field, but realistically, it is impossible to guess what it is like without actually experiencing it. So, being curious, I discussed it with one of the girls in the medical informatics program at RIT. She took the introductory CS sequence and has a large core of Information Technology courses, but I won’t name her so as to protect her identity. I expected some of her responses, but others caught me off guard. My questions are in bold, her responses in plain text. If you have any responses, leave a comment! I’m especially interested in hearing what other girls have to say about these items.
What is it like being a woman in a technical field?
It depends. Male professors really aren’t any different toward me, they are pretty even toward both genders. But in my experience, I’ve never had a good female professor or TA. For example, one of my TAs, a graduate student at RIT, liked a guy in a class I had with her. He liked me, and she knew it – the result was that she was horrible to me all quarter. In another class, I had a male lab partner, and we had a woman leading the lab. She was really nice and helpful toward my partner, but was cold (and frankly a complete bitch) toward me.
I also definitely have to try harder to prove myself as a capable individual. It is assumed automatically that we aren’t as skilled as our male peers, and it gets frustrating.
I thought there would be more cohesion between women in male-dominated fields.
I think girls think it is extra easy for other girls in these programs, so they are complete bitches toward each other. And there is this weird egoism, in computer science especially. Some of them have these little flocks of boys that help them, and they get pretty territorial over them. If you aren’t friends with the girl and you try to talk to the boys in their group, it is bad. I feel like that the culture among girls makes this almost a respected fact, you have to make friends with the girl who is in the group before you can make friends with the guys, otherwise it feels like you are encroaching on their “property”.
Really, I think girls hang out with girls they don’t feel intimidated by. Girls that are jealous of you aren’t going to be friendly, but that is true everywhere.
What do you like about it?
Guys give you help, they generally are less competitive with girls than they are with each other. You can also look like crap, and still get massive amounts of male attention.
Why do you think guys give more help to women?
All the wrong reasons. You know – they like you, they are trying to meet you, befriend you, and they like that you rely on them.
What do you dislike about it?
Team projects suck. All guys think that girls can’t code. It gets annoying when guys have no faith in your abilities. But to be fair, they may have had some legitimate experiences to support that opinion. Guys try really hard to help girls in these programs, and I think having stuff done for them all the time stunts their abilities. It usually shows which girls are doing this when tests and quizzes come about – or when you look at the quality of the code. But we don’t all do it! Guys should really give us a chance before typecasting us.
Would you like to see more women in technical programs?
It would be nice to be able to look up to women, you know, to have upper-classmen girls who know what they are doing. But honestly, trying to imagine more women is like trying to imagine seeing dinosaurs, it is just really hard because I can’t ever see it happening. It would be great in the sense that there would be more hope and encouragement for other girls seeing women getting jobs at big companies with their degrees. It would be more relatable than hearing about a guy doing it.
Do you think there will ever be gender equality in technical fields?
No. Most of this stuff is just not what girls are into. Look at engineering – it has been around much longer, but they are still having problems with female enrollment in engineering programs. I think if there were more female role models in these areas, there would be women to look up to, so other girls would see that it was possible for them to do too. It is kind of a chicken-and-egg problem, we need a lot of women doing these things to attract more women, but we aren’t going to see a lot of women doing them until that happens.
What do you have to say to other women who disagree with you about that?
If they really think equality will happen, that is great! But they should really share it, because I don’t see it. I know a ton of guys that hang around building 70 [RIT's computing and information sciences building. -Robert], but I never see any girls. The girls that are involved with the association for women in computing are nice, but they really aren’t doing anything effective to make the programs more attractive to other women. I’ve seen them once, giving out cookies. I really think it did more for the guys than the girls *laughs*.
Thanks for answering my questions!
No problem.
When looking at a web page or some other piece of hypertext, the pieces of text that are interactive have historically been set apart by some style change. This really refers to links, which in the majority of pages, are the only pieces of text a user would click on and expect something to happen.
As a small tangent before I continue, I have a weird habit. When I read text on a computer screen, I rapidly highlight the lines I’m currently reading from top to bottom, then release and do the same from bottom to top. Repeating this action helps me track what I am reading, By interacting with the text ‘physically,’ I find I am better able to focus, retain information, and process text quickly.
Now with this behavior in mind, imagine a text interface where simply selecting text results in a behavior the user doesn’t expect. If you are having trouble thinking of an example, allow me to point you to a political article hosted by the New York Times, and another from the Free Dictionary on spectator ions. The common feature shared by these two websites is they both have a hidden feature. Selecting and clicking on words will open a new window containing their definition.
This behavior is unexpected, as there are no visual cues to hint that the above action will have that result. Surprising your users with behavior like this is an annoyance, but not having the ability to turn off this behavior results in blog posts (like this one!).
The lessons here are short, and barely warrant a full post as they should be common sense:
- Your interfaces should behave as the user expects.
- Separate your interactive elements visually.
If you ignore either, you risk frustrating the very same group of people you are trying to attract – a behavior that most developers try to avoid.
GOTO is a statement all programmers know. Most of us are too young to have ever actually used it, but anyone with a formal education has been provided with GOTO as an example of the worst enabler of ’spaghetti code.’ So after accepting that something called GOTO is bad, we return to thinking about what we’ll do after class. But why, WHY is GOTO gone?
The disappearance of GOTO can be attributed to multiple factors, most of them well presented by the famous Edsger Dijkstra back in freaking 1968 in a letter to the editor of “Communications of the ACM.” He made some humorous points, such as “the quality of programmers is a decreasing function of the density of ‘go to’ statements in the programs they produce.” Maybe I’m further gone than most (run while you can!), but it made me chuckle. The main points that he was trying to convey however are less humorous: GOTO makes it harder to ‘prove’ programs[1], removes the ability for a programmer to determine the progress of the program in execution[2], and that GOTO is just too primitive of a statement.
After some jokes among computer scientists (see COME FROM – yes, our sense of humor is in need of calibration), GOTO really did start to disappear. Most major language designs lacked official GOTO reserved words, and others like ADA included it using a syntax unique only to that statement so it may be easily found in programs. This disappearance is only surface deep, however.
It turns out that while an unbounded GOTO may result in obnoxious and nondeterministic code, the ability to jump to a segment of code outside the normal flow of execution is pretty handy. ‘Case’ statements are a popular implementation of a restricted GOTO, with one conditional evaluation resulting in a jump to one of many locations in code. More importantly, error handling would be near impossible to implement without the concepts on which GOTO was founded.
Unless the developer is an idiot, error handling is implemented as a catch in case something unexpected happens (I’ve seen it used as part of normal execution, ick). When something unexpected happens, you can no longer depend on the state of execution within the program. In this case, using a GOTO is the only way to break away from whatever caused the error and make some attempt to either rectify it or exit cleanly. Even the parody COME FROM statement has a hidden usage. In debugging, the concepts in which the COME FROM statement was founded are used to handle breakpoints.
So GOTO isn’t really dead, it is just hidden and stripped of its freedom. And more importantly, it can’t die. We rely on its concepts far too much in structured programming to do away with it. Now that you know, spread the word that GOTOs aren’t inherently bad! They are like kids: they just need boundaries.
[1] Loops and conditional statements, and of course functions, can all be reduced to formal mathematical language. Especially when converted to their recursive forms, loops are incredibly easy to prove as being valid with induction. GOTO statements broke this by making code execution able to change state at any time, greatly reducing the ease in which algorithms could be reduced to and proven with math.
[2] Some people might say “hey, loops are kind of like GOTOs. What is the difference?” Or maybe not, but here is the difference anyway. As pointed out by Dijkstra, loops are able to have some index applied to their current iteration or state in recursion (think for(int i=0; i<end; i++) – i is the index). This allows the programmer to have definite knowledge of the state of execution through using multiple indexes as “coordinates.” With a GOTO, this idea breaks because it is trivial to jump to anywhere in the program at any time, making the current indexes useless.
Ajax and the fancy “Web 2.0″ trend are causing all sorts of web applications to pop up. The most familiar examples are the many services that google is making available, and gmail especially. Gmail is, for many people, a desktop mail client replacement. And why not? It contains the functionality that one would expect in a desktop application – viewing mail, composing new messages, and creating filters to sort incoming articles of text. It is a nicely packaged application with a decent interface. It does however have one major flaw: it doesn’t control the application used to view it.
We aren’t talking cross-browser compatibility problems or the folks using text-only browsers such as lynx. The issue that spans all browsers is that they contain navigation buttons. Back, forward, and refresh, these are all elements that can make the execution of a web application occur in an order unintended by the developer. From a software engineering perspective, this presents new problems previously not encountered when designing and developing software. From a programmer’s perspective, this introduces new complexities in the code because the state of execution can change at any time. Additionally, the code monkeys have to handle sessions that may not terminate properly, half-open connections, and navigation issues that will creep up from the user jumping around your application.
A solution to this problem that hasn’t been completely explored is to combine the benefits of desktop applications with the advantages of web applications. Desktop applications are self contained, meaning the interface to that application is completely controlled by the developer. The state of execution again becomes reliable, hooks into the process’ termination can execute cleanup code, and even cross-browser issues may be ignored. Web applications need only a web browser to load them. By embedding the rendering engine of your web browser of choice (as far as I know, Mozilla’s, Internet Explorer’s, and Safari’s rendering engines can be embedded) in an application, the only thing the user see is exactly what you want them to.
The only complication that arises from this situation is the initial distribution of your application. But because the desktop ‘launcher’ application is going to be nothing more than a frame with some logic to handle any initializing or cleanup you wish to do, it is going to be a very small download. And if you are a company that produces a lot of applications, your launcher can be modified easily to support all of them from a single application. Attractive, isn’t it? This also allows for targeting an older demographic that has been slow to catch on to web trends by deploying to them something familiar: an icon on the desktop to be click clicked.
Now for the business stuff. If you already have a solid web application that conquers the navigation and other issues that plague them, you are one step away from redeploying your application to a new market. And while speaking of markets (and thus money), if your application is driven by advertisements, controlling the platform means that the user won’t be able to block your ads. Physical distribution also becomes possible at this point. Your launcher could be bundled with an installer and distributed by CD to be sold on the shelves in brick and mortar establishments. Now your application will be reaching all corners of the current software markets, bridging gaps of technical understanding, and all without your users blocking the media you want them to see. If you are just starting development with this paradigm in mind, you are going to save development time which can be refocused on implementing features for your users. The result is a better web application that is available to everyone.
The benefits gained don’t take a lot of convincing to sell. Simplified development, a cleaner application, and reaching broader markets all from changing the means of distribution?
Money.
Giving your application an icon can be that finishing touch that says “application, I love you.” Unfortunately, the icon designer in Visual Studio 2005 isn’t a very friendly tool for creating nice looking icons. Wanting to make a cow icon for a quick 12/24 hour converter I wrote for my girlfriend, I went running to my favorite image editing program – Paint.NET.
Paint.NET it turns out doesn’t support saving images in the windows-standard .ico format! Luckily, someone was as unhappy with this as I was and created a filetype plugin for Paint.NET that grants the ability to work with and save images as icons. The download link is here. The plugin is awesome, it supports editing and saving images to be used as cursors also. And both formats, icons and cursors, can be saved with multiple image sizes in one file to support multiple icon and cursor sizes. While it is overkill for my application, this feature will save time in the future by allowing icons and cursors to be designed once (as a larger image) before being automatically scaled to each of the smaller sizes. The same feature addresses large icon and cursor sizes for users that require higher accessibility (another extremely important aspect of software development that is far too often ignored) making this plugin an all-in-one hit.
So while my girlfriend will never appreciate the depth and accessibility her little cow icon provides, it makes me smile knowing that in a pinch it could be blown up to all its 256×256 32bit glory :)
We’ll start this one off with a link. Don’t worry, it is just an image (safe for work, too).
The Greatest Programming Tip Ever.
I laughed when I saw that initially, then the title hit me. That really is the Greatest Programming Tip ever. Or at least it should be on the list of top 10 Great Programming Tips, if there were such a thing. Regardless of whether you are working on an assignment for a class, a personal project, or a product for your employer, it is almost certain that someone is going to look at your code. Writing readable and easily maintained code is important for this reason, but for different reasons.
If you are going to be writing code for a class, you had better put some time in making sure your code adheres to your department’s style guidelines. For the computer science department at RIT, this was actually factored into our grades on labs and projects. Even if it weren’t, your professor is going to be more frustrated than impressed with a piece of code that lacks comments and is filled with ternary operators. Comment your code to explain things that aren’t immediately obvious to a first year CS student, name your variables to be descriptive of their function, and make sure your program flows well (no spaghetti code). This will make your professor happy, thus boosting your grades.
For personal projects, it is just as important to follow the guidelines above. While there may be no one grading your work, consider that friends, future employers, and future-you may look at the code later. Embarrassingly, I can’t even count the number of times I’ve rewritten those run-once-every-three-months kind of scripts because I didn’t take the time to comment them. And if I had put those scripts on a public source repository (which I fully plan to set up soon), employers would eventually see it. I want the code I present to the world to reflect that I am a proficient, clean coder. You should want that for yourself.
Now here is the big one, your employers. If you are working for someone, that almost definitely means you are working on a team. In this case it isn’t just a matter of writing readable code so you can remember what you’ve done when you later have to fix a bug in the code. No – things have become amplified to a factor determined by the number of people on your team and the number of those team members that have to maintain your code. I know from experience the pain and delays that can be caused by terrible code, and I won’t lie: it happened way more often than I’ve blogged here. It dragged down the morale of our project team, caused huge delays in our production (on the magnitude of weeks of developer time over the past six months), and made the codebase impossible to maintain cleanly. You do not want to be the guy that is responsible for that. Best case is you lose your job, worst case is management turns a blind eye to the project team hiding organic material in the corners of your office (give it a couple of weeks, you won’t enjoy it).
Go out and do some reading on writing readable and maintainable code. Aside of learning the basics of a language, it is the single greatest thing you can do to improve your abilities as a programmer.
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!
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:
- The system must be able to store and retrieve which members were present at a specific meeting.
- The database will be on a central server, but the client must be multi-platform and portable.
- The system must be able to able to verify on some level that a member was physically present at a meeting.
- 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:
- The system must be accessible in the absence of an Internet connection.
- 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.
- 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.
