Thursday, December 26, 2013
How Do You Debug Your Application?
I'm nearing my self-imposed deadline for a beta (well, alpha release is probably more accurate) before I cut this project loose and start moving into something new. And of course, I ran into a glitch during what was supposed to be a simple feature addition.
What was supposed to be a simple sample program had become a bit of a mishmash in goal alterations, so the simple thing I originally mapped out in my head was now a little more complicated. How was I going to troubleshoot this problem?
I did it in what is probably the hard way. I would place messages in various spots along what I had traced to be the application's flow of logic. If it were about to call a subroutine, I placed a message box with a diagnostic message so I'd know that the program had hit that particular area of code and, when appropriate, it had diagnostic information about the state of a particular variable.
This way of thinking probably goes back to my first programming experiences using environments like the built-in BASIC interpreters in the Commodore and Apple II. Even when I graduated to QBASIC-esque variants there weren't many great options in debugging; later, in college, I was working in C++ IDEs where debugging facilities had improved, but we rarely worked with them. Instead the assignments tended to be small and inserting hand-made breakpoints into the application meant getting the assignment completed in time and in usable shape.
There wasn't really any emphasis on using the debugging tools.
I suppose at some point the idea of inserting code that let me know what was going on at certain points in an application became a "cross platform" way to debug a problem. I didn't have assignments or projects so large that specialized tools were necessary, and even if I did need to run a tool for debugging, I was afraid to invest a lot of time into learning a tool that would only work with one environment on one platform. It makes me relive memories of support issues past when we had people flip out because a menu changed in a new release of Office; they became dependent on the clicks to accomplish a goal rather than the skills to navigate to the feature they're seeking.
At the same time...like when I was creating this application...there were points when I wished I could easily have the IDE step through each line of execution so I could see what exactly happened at each point in execution flow. And part of me thinks this has to be built in to the Visual Studio IDE and is blatantly obvious to seasoned programmers...there's just so many buttons that by the time I figured out how to do what I wanted to do, I'd probably have solved my problem three times over using my rudimentary system of debugging.
It occurs to me that I hadn't run into a case where debugging tools were taught, required, or demonstrated. "Insert code here to tell the programmer what is happening at this point" was portable...it works in compiled and scripted applications and in most languages...and seemed rather intuitive.
So how much am I missing in approaching debugging this way? Is this even a legitimate method used by professional programmers?
Is there a decent tutorial for a preferred method of debugging, or how to approach debugging? Or is debugging another skill acquired with experience?
I suppose I should fret over this more, but my next project will involve playing with some Ruby on Rails; Visual Studio's built-in debugging tools will probably not be of much assistance there. I suppose this also means having to figure out a different way to debug applications with the change in platform...
Thursday, December 19, 2013
Releasing Your (Software) Projects...Self-Imposed Feature Creep
It started as a curiosity, a toe-dip into the pond of testing my rusty brain. I wanted to experiment with something that had been floating in my head a little while.
For the most part I got the core of the application down. It's simple. There's a lot of room for improvement, granted, but it was relatively simple. And I really need to test it out, once I get one more piece of behind-the-scenes functionality implemented.
See, that was part of the problem. Even though this was supposed to be a neat little proof-of-concept test application for me to take a concept and make it work, I still ran into bumps where I ended up wanting to tweak it a little more. I only worked on it a little bit at a time; usually an hour or two after work a few nights a week. Which isn't optimal for the way my head works. I usually need a large block of time dedicated to sorting through a problem and figuring things out; but if I wanted to get to work in the morning feeling like more than a zombie, I had to get to sleep at a decent time. So that kind of limited my time spent on the project.
Then there is the podcast. I currently spend an hour recording, around the end of the workday, the audio material. Then I typically spend an hour and a half to three hours total going through the material, editing it, taking notes, and getting it posted to the feed site on Tuesday so it will be available to my meager audience on Wednesday. That takes about two nights off my "available for hobby" schedule.
Every time I got close to feeling like, "Eh...it's good enough for government work..." I come up with one more thing I want to investigate or tweak. Some design ideas I abandoned from what I originally had in mind...usually because of time, or the thing I wanted to do just wasn't of high enough priority to make that particular item worth pursuing.
Little tweaks kept calling me, and given that I'm rustier than the Tin Man after a rainstorm, it takes me longer than it should to put a tweak in place. I'm even more handicapped when I insist on doing it in discrete blocks of time after work a few days a week. It was supposed to be a small proof of concept thing...not a full on project!
Thus was another lesson in software projects. Without the mapping and specs pre-mapped, as I've mentioned before, you end up feeling like you need to keep altering and tweaking the program ad infinitum. You need a set of goals lined up so that at some point, you just say, "It's done." Maybe it's not really done, but it's met the spec.
Of course part of it is, no doubt, embarrassment at how it would be received, since no serious programmer uses VB.Net (of course.) I'm not entirely sure why this is, since .NET languages largely compile down to a common language runtime (which is the whole point of .NET as I understand it...) so...maybe it's a fear of the culture. A side effect of working with smart people is feeling like you're always one or three steps outside the pack.
I need to move on to one of the projects I've been wanting to use for learning Ruby, which means I needed to come up with a deadline to stop this current experiment. I decided that there is one last thing I wanted to try to get working, and after that is finished I'd show it to my manager for a bit of a constructive criticism. My deadline will be the new year. I'll take my system home with me over the holiday and work on the last feature, then come the new year send it his way to have a look.
It'll be a mess, no doubt; I have no illusions that it did things "right" all the way through. I really should have focused on using classes to implement part of it rather than my mangled hard-coded approach. And there are definitely parts that could have used more error checking.
On the other hand, it was the first time I'd approached a programming project in some time. And the end result was that the basic idea, the basic functionality, worked. Given more experience and time it probably would turn out better. I really need to keep working at it to develop better habits and solve more problems, and I need to move on before everything becomes an excuse to procrastinate. Then nothing will get accomplished.
To try keeping myself on my self-imposed deadline, I asked my manager if he could take a look and offer some constructive feedback come January; having someone else know about it might help keep me on my timetable. So there it is. Over break, I'll spend some time polishing it slightly, then test it out, then have it reviewed by someone in a position of experience to tell me how full of blech it is.
Then I can move on to the Ruby tutorials and create a whole new type of blech.
Saturday, December 7, 2013
How to Start a Podcast
Generally speaking I end up gathering a couple of items over the weekend to talk about and add them to a Trello list dedicated to tracking podcast items. Not that I dedicate the weekend to this task, but it's a task I set a deadline of accomplishing on Saturday or Sunday so there is time to have things organized before recording.
Lately I've been recording on Monday night. The podcast ends up being about an hour (aim for 45 minutes, end up being an hour...) If I'm up to it, I can get to the apartment and begin editing, although usually that is a task I dedicate to Tuesday night.
I take a fairly loose approach to the podcast; there's not much to edit. I insert some intro music. I tack on some outro music. I edit the podcast to trim pauses and extraneous bits, shortening the recording by about...oh, five minutes. Really much, if not most, of the recorded material ends up being the podcast. No special effects, not much in the way of inserted material. It's a recorded chat with bullet points.
What am I using to record?
We...my recording partner and I...are decidedly doing this on the cheap. I use a Macintosh with Garageband to do the actual recording. I splurged on purchasing a couple of USB microphones, which makes a significant difference. Those things are sensitive. They pick up keyboard keystrokes and pens clicking against the desktop. Believe me...you don't want to fidget or eat or drink while recording. If you can, open any show notes and links you may need ahead of time to minimize the noise factor.
My cohost is normally remote, so we use Google Hangouts to collaborate. When Pete is available to cohost he normally creates a recording of himself on his side of the conversation.
Me, I use LineIn and Soundflower for the Macintosh. It's a kind of virtual audio device for redirecting audio input and output. Here's what I do...
I first have a copy of LineIn created (so there's LineIn and LineIn Copy.) And after installing Soundflower, I have an additional 2ch and 64ch virtual sound device on the Macintosh. I launch LineIn and tell it to use my USB mic as the input, and for output use the 64 channel device. In the same application I can tell it to use the stereo channels 1 and 2 for that microphone.
In the second copy of LineIn, I capture the 2ch device for input, then as output direct it to use the 64 channel virtual device as well, only using stereo 3 and 4 for output. Click "pass through" for both, and sound should now jump on the meter when the microphone picks up noise.
Next launch the Google hangout, and link up with the cohost. I tell the hangout to use, as output, the 2ch device. See where this is going?
At this point I have the microphone funneled into channels 1 and 2 on the 64ch device, and the Google Hangout funneled into channels 3 and 4 on the 64ch device.
Garageband is another example of an Apple application that is adequate for basic home use, just adequate enough that it gets frustratingly irritating if you want to do anything more than the basic home use (if you're do that, you're doing pro work, and they firmly believe you should pay gold bars to afford the privilege of doing something more advanced than the absolute basic home use features...) That means that it takes as input one device. Now you know why I am using LineIn. LineIn lets me take two "devices"...sound from the Hangout and from my microphone...and mix it into one device Garageband can see. Tell Garageband to use the 64ch device as the input, and then create one track for the microphone and another track for the hangout.
The microphone track uses channels 1/2 stereo, and the Hangout track uses channels 3/4 stereo.
I enable multitrack recording and show the track monitoring. When I monitor I should be able to hear the sound from the Hangout.
For sound output, I can use the default or headset or whatever is handy; but recently I was experimenting with the idea of interviews. This creates a new set of issues, since my microphones are sensitive enough that they can pick up both voices, despite careful tuning and settings twirling. On of the more obvious problems if the remote person was to talk to a guest was, how would the guest hear?
Once again, fixed on the cheap. I had a USB headset and I had headphones connected to the built-in output on the Mac. The Mac has an "Audio MIDI Setup" utility included; in this utility you can create what's called a multi-output device. This takes however many sound outputs and aggregates them into a single virtual output device. Create the device, checkmark what hardware you want to include in the virtual output, and voila...sound is sent to all the devices simultaneously. Now if you set the Mac to use the multi-output device as the default output for sound, anything coming out of the hangout (through GarageBand) will be heard on both my USB headset and the built-in output device at the same time...so a guest being recorded will be able to hear a remote co-host.
Back to Garageband, I click on the multi-record for the two audio tracks (and third, if I'm recording on a second microphone for a guest) and...we talk. For about an hour, give or take. Go over topics, whatever springs to mind, while trying to stay mindful of the time we've taken so we don't go much over the hour and we try to stay in the vicinity of the topic. Of course, room noises are cut down during the session; fans off, bubble-lamps are turned off, etc...anything distracting that might get picked up on the recording I try to minimize.
In our setup, after getting the recording finished I get Pete's recording of his own voice track. This gives a generally cleaner copy of his side of the conversation, without the compression noise or packety static from the Hangout mingled in with his words.
I drop his track in, line it up with my own track so the words line up in the right places, and then go to work chopping away and inserting music.
Once the intro/outro/chopping is done, I export it as an MP3. Plain old MP3. Garageband has support for artwork and such...enhanced audio, I think they call it?...built in. But if you use MP3 format, it won't export with the enhanced features. Go figure.
I then import the MP3 into iTunes. Open the Get Information inspector element, and then click on the album art tab and from there add the graphic for the podcast. Close it out...it'll save the ID3 tags (the artwork.) Then from iTunes I tell it to show the file in Finder, make a copy of it to an outside folder, and delete the iTunes copy.
The last steps are to upload the file to my storage provider (I already use their RSS feed to ping it out to the iTunes store, so I can edit the information on my storage provider and it'll ping Apple for me to push it to the Apple store.)
I wrap it up with a trip to the blog on Blogspot for the podcast and entering the shownotes there, along with links to my hosting provider. Done! I tweet it out to the world, and tens of people see that it's ready to listen to.
I'm not overly specific in my description, I know. I could give a step by step tutorial...really, it's specific to my workflow, and the specific steps aren't as important as the end goal. Podcasting is one of those things in which there are a myriad number of ways to achieve the end goal of podcasting and no single "this is how you do it" methodology behind it.
At the most basic level, it's creating an audio file, sticking it on a host server and making sure that host server allows an RSS feed for listeners to subscribe to. That's it. I still get surprised when a "hip teacher" will have a class "record a podcast" when in reality they're just recording an audio file and sharing it...the cast part of podcast is supposed to allude to the idea of broadcasting the file, so if you don't save it to a (mostly) public server for people to subscribe to, it's not podcasting. You're literally making a recording to share.
Get it right already...
After that, there's all kind of variations for what you can do to prettify and spruce up the podcast. You don't necessarily need album art; but iTunes kind of penalizes you if you don't have it. We have swearing and references to boobs in our podcast, so I make sure the explicit tag is set in the ratings. You can set enhancements to the audio so there are set chapters, and changing album art so people who watch your podcast with the proper viewer can see a virtual slideshow.
How can you record? There are people that use the built in microphone on the computer (although...yuck. It's quite noisy and not great at picking up your voice well.) Or do what I did and get an inexpensive USB mic. Other people buy USB mixers to control the microphones. Others get handheld devices made to record their voices, or even get microphones for the iPhone and import their run-and-gun audio into iTunes to be edited within Garageband. There are still other podcasters that have the equivalent of an actual studio set up; I know Scott Sigler records his podcast novels in a special closet lined with sound-absorbing foam to maximize his recording quality. Sure, it cooks him when it's a hot day and there's no AC in his closed mini-room where he is sitting and sweating his ass off during a recording session, but the sound quality is fantastic.
Sound editing for post processing can be free (Garageband!) or there are expensive audio editing suites. Much as with the microphone options (free built-in mic on the laptop up to microphones costing hundreds of dollars plugging into a soundboard for audio amping and mixing) the software editing choices depend on what you're willing and able to spend for the final product.
Hosting your audio files is quite a decision to make...moving your RSS feed later, especially when you're tied to an aggregator like iTunes, sucks. Fortunately I haven't had to do this, but I've heard other people doing it, and they all generally had the consensus conclusion that it sucks as a process.
There are free options...but the consensus I found while researching was that the free storage from places like archive.org delivered slow access, as they generally didn't have money to spend on infrastructure to deliver content at a decent pace (after all, it's free. What are you complaining about?)
If you have servers set up for other purposes, you can go through the steps to create a server for storing the audio recordings and dishing out the RSS feeds. Maybe it's more for a "low cost" solution, as you can get storage relatively cheap, depending on your bandwidth usage, from a cloud provider like Amazon. I didn't want the additional hassle of maintaining the servers though.
Actual podcast providers usually have accounts set up for relatively low fees, and they often throw in bonuses like not having to edit those God-awful XML feed files and perhaps even a nice stats page added to boot. Libsyn is very affordable, has good support, and so far I've not regretted using them.
Some people think that iTunes stores podcasts. I mean, they invented the term "podcast" in the first place, right?
Well, they did invent it, they did make it popular, but they do not host your files. They are an aggregator and search engine so people can better find your stuff. You're responsible for finding the server on which to store your files for users to download. iTunes is a simple (and free) way to get people to find your stuff. Using the iTunes store to get users is a purely optional thing, if you think you can get more people to directly subscribe to your show via the blog or your show host account.
While my storage provider has a "show blog" feature for show notes and such (show notes...where you put in information like links to what you've talked about, or a summary of the show for reference, and/or contact information...nice search-engine features to enhance your show information) I preferred using Blogspot to power a show blog. I didn't want to set up a mail address as I knew it would solicit spam, and while my show isn't all that popular, it's a waste to have mail resources tied up as yet another thing to monitor and maintain. The blog allowed me to create notes while also allowing feedback from listeners if they were so inclined, plus Blogspot was free. Want to give feedback? Just leave it at the blog! It archives my show notes, it lets me link to an embedded player, and it provided transparent feedback from users while cutting back on spam.
To elaborate on my original "what's a podcast" definition...
- Create an audio file
- Upload the audio file to a server with an RSS feed
- Create a presence for your show notes and information...such as with a blog.
- Create the audio file
- Edit the audio file for an intro and outro jingle...remember to respect copyright
- Edit the pauses, um's, and errrr's out of the file
- Add album art
- Upload to a storage provider
- Edit the description of the show, edit ratings
- Create show notes that are accessible to potential and current listeners
I've enjoyed experimenting with podcasting. I definitely have a face for radio, I enjoy hearing myself talk, and I'm generally opinionated, plus podcasting gives you practice. I am hoping to integrate some form of interviews into my podcasts so I can practice talking to people and getting to know them better; interviewing is a separate, special kind of skill if you want to do it well.
Managing a podcast is also a special skill; I can see why some productions end up hiring producers and editors. Not just for the obvious...I've been doing a podcast for a few weeks now, and we don't have many listeners. Which can get disheartening. It's hard to grow a listenership, and we're still tweaking the format. There are a LOT of podcasts out there. Standing out is nowhere near as easy as it was a few years ago. It takes dedication to not podfade, the term for a podcast that kind of...disappears. Editing takes more than twice as long as it does to record (although after having to set up the equipment and routing audio for the session, I sometimes question that...) because if I record an hour of audio, I have to listen to that hour, stopping to chop out parts of pauses or sound glitches along the way, and backing up to listen to the portions I cut to make sure they transition properly. Hour recording...another hour and twenty minutes listening and cutting and making notes for the show notes...then time to type up those notes and do the actual upload to the servers...that's why I end up scheduling a night for recording and another night for editing and upload.
And why, you see, I started off saying that my programming project got squeezed just a little bit more. I know have about two or three nights when I can tweak that program a little more. I promised myself I'd get the show up before Wednesday each week, and so far I've been doing pretty good with that. Late Tuesday night I'm tweeting out the show links shortly before midnight rolls around, and I'm patting myself on the back that I managed to produce another show on schedule and on budget.
But I really find it fun. I suppose that part of me wishes I knew how to integrate this into my job with supporting technology, or integrating learning to program with podcasting. It could be quite a blast for me...but in the meantime, I'm going to keep aiming to get these out on time, and trying to slowly grow a listener base.
"Good morning, good day and good night!"
Saturday, November 23, 2013
Selfies. Seriously. What's the Big Deal?
Large parts of the article seemed to make sense, or at least confirm my preexisting biases. Which for me is the same as confirming that large parts of the article are correct.
Selfies seem to be a popular form of validation on social media. I mean, why else would you post a picture of yourself making a stupid duckface?
And there seems to be a particular set of demographics that are more inclined to doing it. Hint; you find them as werewolves in Twilight and fans of Twilight.
Some things I do get; I get the images taken of some kind of accomplishment. Hey, I just graduated! I just passed the Bar! I'm drunk off my ass in a bar!
These are images that are about something more than just yourself; you're trying to convey something of meaning or worth remembering. I can relate to that.
But the image of just yourself sticking your face in a camera lens to put online? What is it trying to say or convey?
"It doesn't have to say or convey anything! I'm just having fun! I'm being MEEEEE!"
That is more along the line of what the article said was narcissism. It's being posted for some kind of validation. "Aren't I pretty?" or "Don't I look great?!" They boil down to, "Look at MEEEE!"
This isn't a direct criticism of the behavior; it's our culture now. We love the idea of being validated by others. It's what social media is largely about. We post things in blogs hoping others will see it and tell us it's useful or great or that we're right, validating our opinions and feelings. We post crap to Facebook looking for likes or positive comments. We post things on Twitter and count retweets as affirmations that people love us.
Selfies are just another way of vying for attention.
So I'm puzzled when people blow up at this article. Sure, I disagree with the notion that selfies are a way to validate the idea that women are living up to a societal norm of what's beautiful; and I disagree with some of the characterization of what is and isn't a selfie. But it's not something to turn into a social cause or stir up righteous indignation.
I'm also puzzled when people say that selfies are "empowering." Empowered to do what? Is this a buzzword hijacked as shorthand for some cause that I've totally missed the point to? Usually empowerment means you have the authority to do something. I don't know how a teenager taking a duck photo of themselves or a guy showing how ripped he is at the gym equals authority to do anything.
There are also people who say they take these pictures because they don't fit social norms and don't care what others think of them. Which is great...but why'd you share the picture? I mean, isn't the purpose of showing something like that to seek feedback? Or are you expressing yourself in a way that elicits feedback while trying to show people you're such a badass you don't want that feedback? I just don't get it.
The only explanation I can come up with to reconcile the amount of ire drawn by this article is that people are overly sensitive to the framing of the idea; they object to the negative connotation of narcissism, or the idea that they're seeking validation in their behavior. Naturally they show how wrong this idea is by posting selfie pictures in droves with others, tagging the pictures so it trends as a Twitter topic with the hundreds of other outraged selfie-takers, in a totally not-ironic group behavior.
It's possible I'm being overly narrow in my definition of a selfie. The article had as an example a group of women in the Marines posting a picture of themselves after completing infantry training. I don't think of it as a selfie; it's a group of friends, or colleagues, or...whatever they consider themselves as a group of people having gone through and successfully overcome a big obstacle as a team. Just because your face is in it doesn't mean it's a "selfie." It's a memory to look back on.
But for people itching for a social issue to fight over, especially if they view something as criticizing something they themselves do, technicalities don't need to stop them from firing up the hate wagon.
This is simply another topic I chalk up to, "I just don't get it..." and I doubt I'm going to get any level headed, rational explanations any time soon. I'm open to explanations. But when it comes to teenagers posting pictures just because "I feel awesome!," you'll have a hard time convincing me the motive isn't a hope to have lots of people chime in and agree that yes, they do indeed look awesome, and anyone moved to disagree is asking to be dismissed as a "hater," another bit of Internet-emergent memedom that is equally vapid in popular meaning.
Do you have a better explanation for the meaning or motives behind a selfie? Is it something more than just begging for attention in a culture that prides itself on shallow attention for the sake of attention? Or is it as the article mentioned from yet another article, a way for women and younger girls to self-promote, seeing as boys are encouraged to self promote while women are being held back from doing so?
Monday, November 11, 2013
Personal Programming Projects, Not Always Simple
My own project, without getting into too many details since it's still embarrassingly amateur, is at a point where it seems to work "well enough" that it could serve as a simple demo. In the process of getting to this point I've made a few observations.
One, if you lack a good spec that maps specifically what features you want and how to use the application, you'll probably end up with cruft that does little more than takes up space. I made a pass at the source code to clear up some test calls and experimental stuff I threw in. One function was called once, and it carried a "test" notation. The function itself described what the function did but not why I put it in there. I think I at one time had an idea for the program to do something that this function would help with later, but at a point after the application took shape the scope of my project kind of changed.
Two, it's probably a good thing to periodically go through and clean up extra crap from the code. It's a lot less to search through and trace when something goes wrong or wonky.
Three, just because it compiles and seems to work doesn't mean the impostor syndrome will fade. I suppose that by acknowledging there's a possibility I am working under the shade of the impostor syndrome umbrella I'm not actually experiencing it, but that's a rabbit hole I don't feel like pursuing here. Lacking experience in the field contributes to the feeling of frustration and inadequacy; I don't know if a problem I run into is similar to something my colleagues would run into or if it's a rookie mistake. In one example I was running a rough bit of approximation math to figure out if a couple of controls overlapped, then felt hugely stupid for not thinking sooner that there would be a method built into the libraries for detecting the collision of the controls.
Google told me there was a collision detection method. I experimented a bit, but it seemed that it didn't work properly, or at least not in the way I expected. Narrowed down Googling suggested that these particular controls don't do collision detection; the proposed solution was the math route I was first pursuing.
Four, keep track of your development work, for a reminder if nothing else. Maybe more experienced developers don't need to bother doing this, but I find a personal journal to be handy sometimes. Nothing too elaborate. I just go back to remind myself of what I've done and how long it's taken to do it. Days blur together over time...the list of what I've managed to do in my sessions helps jog my memory and keep me from thinking I've accomplished nothing.
Five, keep track of your issues and goals. I was keeping paper notes before, but now I've opened a Trello board to create notes. Think of a feature to add? Create a card for it. Find a weird behavior? Create a card for it. I simply created lists to classify the issues...features, quirks, etc...and then shuffle the cards around as tasks are completed.
Trello is a list of lists, not really meant for user as a bug or feature tracker. But for my needs keeping track of issues as a series of handy lists is adequate. Maybe professionals have a better way of achieving these type of tasks, but I'm not working on a team nor working on a giant project. Do other programmers or teams use Trello for tracking software projects, or particular aspects of software development?
Six, there's more than one way to achieve a goal, but figuring the "right" way takes experience. At least, I think it does. I've read conflicting accounts of the "right" way to design the logic flow of a program; what should go into a function? How big should functions be? What should go into a separate file? Are there certain practices that work for a single- or small-team program that others would cringe if they saw it?
I recently read of an analysis of firmware used in an embedded controller that apparently ignores most of what would be considered "best practices," yet was...is...in use in a number of cars on the road. Presumably this code was written by people who are experienced programmers.
I've also read more than one case of coders eviscerating other coders work as inept or incompetent.
Is there a set formula or best practice for doing this? Or is it a learning through experience thing? Or in the end, does it just not matter as long as it all compiles and runs as intended?
Seven, programming can be difficult, and there's a learning curve to even using the tools that makes this more difficult. A very long time ago I created elementary programs by typing line by line into the memory of a Commodore 128, TRS-80 or Apple II. Later on I typed lines into a text editor, creating a single document from which an application would run (or compile, depending on the language.)
Even later on I could create a large text file that contained most of what I needed to compile into an application. Certain libraries or adjunct modules could be created in extra text files and compiled in with includes.
Today's version of Visual Studio is simply overwhelming to the uninitiated. More confusing is the fact that you don't even need to touch three quarters of the features and still create a working elementary program.
Discoverability is remarkably difficult, despite great features like Intellisense to auto-complete what I'm typing, I was unsure how best to figure out if these particular controls were overlapping; there's a method that seemed that it should work, but it doesn't. Despite an integrated environment that looks like it was ripped from a futuristic movie, I am still scouring the Internet for example code to figure out how to do what I'm looking to do.
Some parts of the code seem to work as if by magic; it's most likely a deficiency in experience, but sometimes tracing what is happening at what point in the execution of the application is difficult, despite everything in the IDE meant to help with debugging and tracing the execution path.
That's what I miss from using simpler tools and text editors. There seemed to be less magic involved in debugging as well as understanding how and why things worked in the process; I know that if I were involved day in and day out with Visual Studio things would make more sense, but as someone using it sporadically, it's still amazingly complex. I liken it to being able to make a car start, go, and stop, but having no idea how to use the A/C, stereo or even the cup holders.
Once I can finish the personal project, I'm moving into playing with Rails. Ah...a text editor to create a usable application? Let's see if that suits me better.
Eight, your small project is not immune to feature creep. This may be related to not having a complete spec created beforehand, but as my own project evolved, I find myself not wanting to show it until it has all the side features implemented. Most of them would probably not even be visible to the end user, unless something goes wrong.
It could be argued that some of the items I'm looking to implement aren't really features, but rather bug fixes. "This works well enough, unless the network doesn't exist...it needs to check and throw an error to the user if that's the case" is a little different from adding a way for the user to control what color a font is. In this context I simply have added conditions to check for before being willing to release this as a 1.0 version for the scrutiny of others.
Nine, I'll never be comfortable showing my work. Anyone can come up with excuses for why something sucks. Working around people who are very good at something, and not working in a learning or apprenticeship capacity, makes the prospect of showing something to others quite intimidating. Primarily because I have no illusion that this is great work.
Then again, knowing that this could be ripped apart with questions of, "Why on Earth did you do this?" and, "How did this compile?" as a feared inevitability also implies that there's nothing really to lose, other than ego, in facing the feared inevitable. I'm not a programmer by trade, so it's not a direct insult to my competency. It's also not something I'm paid to do, and the act of creating this means an opportunity for constructive feedback from which to learn, if someone is willing to take the time to explain why something should have been done a different way.
These are the latest rounds of observation for my little project. I don't have a release date yet; my goal is to keep inching towards completion, which I am. Progress is progress, even if it's just in hour-chunks each week...
Wednesday, November 6, 2013
Drones over Manhattan
Perhaps the most blatant illustration of word choice used to play on emotions can be found in the ever-popular abortion issue. "Pro-Choice" and "Pro-Life" are certainly better labels than "Anti-Choice," or "Pro-Murder," right?
Spin doctors want candidates and practitioners to stay on message, and reiterate the short sound bites ad infinitum. Perhaps this works with issues that people don't become invested in personally. Perhaps it works on a spectrum such that the use of these phrases still affects people despite being aware of the verbal trickery and manipulation. Or perhaps the simplest explanation is that too many people unskilled in the actual "art" of spin doctoring become armchair spin doctors, stealing dumbed-down terminology from headlines the way high-schoolers copy and paste online articles to pass off as their own work.
The reason I bring this up is the headline, "New Video: Drone Crash Lands in Manhattan" crossing my news ticker. A drone! In one of the busiest areas of New York City! A DRONE!
Drones have been in the news recently for being used to kill who-knows-how-many civilians in countries somewhere over in Theyhaveouroilistan. These are Predator drones...remotely controlled bomb delivery and video surveillance systems piloted by military personnel miles away from the target area. This is the image that is being ingrained into us both by the "See our nifty toys" division of the military and the humanitarian agencies denouncing their use.
But in New York! Our own soil? The images conjured up when I saw this headline were flashbacks to episodes of Dark Angel, where the police used small autonomous devices that buzzed about the city gathering video footage for surveillance purposes. And there have been headlines hinting that police departments would be interested in testing such technology.
Surely this would be interesting news! So I clicked on the headline.
What I got was more of a lesson in sensationalism.
As it turns out, someone took a radio controlled quadcopter with a video camera and started flying it around Midtown. After taking off from his balcony and bumping into several buildings, the copter finally took enough damage (or ran out of charge) and fell to the sidewalk, "narrowly missing" someone who called the police.
This was their drone. A toy copter with a camera onboard.
I suppose it can be, by strict definition, considered a drone. It flew. It had a camera recording its flight. Maybe it even transmitted the visual information back to a receiver at this guy's apartment, and he was flying it by the camera and not by giggling and randomly moving the control stick.
But this also puts a child's toy on par with a million dollar piece of military hardware. Or at least in the eyes of the news reporters, who in turn sensationalize it for the public, making it seem as if terrorists or big brother are hovering outside of your window to watch you undress.
There was a time when teachers and school librarians scoff at the idea of students using online resources for research; "Anyone can put something on the Internet without making sure it's true!"
They begrudgingly started allowing Internet citations as more news agencies started posting material on websites. The next thing I remember being on the banned list were Wikipedia articles, because "Anyone can post information to Wikipedia!"
Now they begrudgingly allow Wikipedia to be used as a "starting point" for research papers.
There's a taste of irony when I see how the accepted, vetted, trusted sources...such as this news channel...in a bid for ratings, and in an attempt to beat all the non-vetted, untrusted Internet sources, doesn't hesitate to skew news headlines beyond the point of being misleading.
Ratings through word choice. Manipulation of public perception through word choice.
Maybe teachers should re-emphasize the importance of the thesaurus when reviewing the Common Cores.
Wednesday, October 30, 2013
Halloween Fun: Jekyll and Hyde (Club)
This of course leads to a series of minor hijinks in its own right, as is typical for the way life moves along. I thoroughly enjoy Halloween, horrors, and general spookiness, and my Mom is not a fan of many of the places my wife and I typically enjoy, so I thought I'd finally try the haunted scary house themed restaurant near the Port Authority (with the conveniently located A-C-E subway line only a short walk away...like, across the street from the restaurant) that I'd been eyeballing whenever I happened by that area.
I thought it was called the Jekyll and Hyde Club. I'd even seen a vehicle driving around Manhattan with skeletons and zombies, making it seem like it could be a cool experience. My parents, as part of my birthday, sent some money along with a note to get in their club membership so we could get seated more quickly.
I don't often go to Times Square. It seems most New Yorkers don't need to elaborate on this explanation, but for those who aren't living here, I'll just say that my idea of fun isn't having to shove through a mass of shambling tourists and leave it at that. I kept putting off getting the membership until my wife came to visit over Comic Con weekend, when I knew we'd probably, at some point, end up going through Times Square.
My wife looked up the restaurant for some information. This was when Google said the restaurant was permanently closed.
"That doesn't seem right," I said. "There were people soliciting guests outside not long ago."
She noted the address and said, "We could take a look and see, just to make sure."
We started heading to the address when I realized this was not the restaurant I thought it was. I was actually thinking of Times Scare, and the Jekyll and Hyde Club was something totally different. Whoopsie.
When we arrived, we discovered that no, it was not closed permanently. It was quite busy, as a matter of fact, with a very, very long line to get in. We weren't looking to have a meal; we just wanted a membership. We talked to the guy controlling the line at the entrance, and he pointed us to another door that led to their gift shop/exit.
It was at this point that we found a contrast to another restaurant that offered memberships; when we first went to Bubba Gump's in Times Square, we were offered their membership; one of the bonuses was to get early seating. We pay extra for the membership, we get to jump line.
Both the doorman and the girl at the front desk said we could get a membership, but it would not allow for us to jump line that night. "It wouldn't go over well with the people in the line," said the doorman.
We assured them that wasn't our goal, but rather we were preparing for a return trip in a week or two. It was a little off-putting to be reminded that we were paying for a privilege that was essentially worthless upon joining, however. I suspected they wouldn't have minded us using the membership card for discounted and members-only purchases in the gift shop, though.
Upon joining, we got a few items to designate our membership status. One, a cardboard membership card; I'll admit, I was a little disappointed that it was cardboard since that meant it would be less resistant to damage in the wallet. I was hoping for a plastic card. But as long as it serves its purpose, I suppose that's good enough for me.
In addition to the card we received a pin and a huge certificate of membership; like, posterboard sized. The pin was a nice touch; but I don't normally wear pins. The giant certificate was puzzling to me because it was rather impractical. Theatrical flourish, perhaps? If so, it fits with the theme of the restaurant.
Fast forward to the dinner. True to the promise of the membership club, we showed the doorman our membership card and he pointed us back to the same door leading to the gift area, instructing us to show the clerk the card. We were then pointed up a set of stairs to be seated by the hostess.
The skeletons seemed to be a nice touch. |
The case has skulls and heads. The Pharaoh's mask reminded me of Stargate. |
Turns out many of these objects are animatronic.
And the ancient dead king spoke English pretty well, too |
In addition to the speaking knicknacks and statues were costumed actors engaging the diners in character. We talked to an assistant to Dr. Hyde and a "social director" for the club. I can only imagine how awkward it must be for them to have uncooperative guests, and imagine they often do encounter them. I don't envy their jobs at all, but they do add to the ambiance.
After a few rounds of the talking statues a live show was performed on a stage below us.
Rise! Rise! And shine! |
Oh, and I got a signature glass with an order of a Zombie. I like getting signature glasses at themed restaurants.
The theatrical display, the ambiance, and the actors were pluses. The biggest drawbacks were the prices and our waitress.
Don't get me wrong; this was only slightly more than Manhattan expensive in terms of restaurants, and there were five of us at the table bringing a bill to around $200. This was quite a splurge, one I don't anticipate repeating for a very long time! But it was to be a special birthday dinner and apparently my parents had been saving up for the occasion. The menu had a note warning customers that the bill adds an extra $3 per person as an entertainment fee, on top of the Times Square food tax (read: tourists tend to pay extra to eat in Times Square.) For most people from my home area, this would be quite a sticker shock. On the other hand you have to think of this as not just dinner, but dinner and a show. Then the pricing makes a little more sense.
Plus I got to keep the signature glass.
I should also note that the desserts my mother and wife ordered were, from what I was told, "Awesome!"
The other drawback was our waitress. Service was beyond slow. The actors talked to us before the waitress. We at first thought another table was being a pain, as we thought we saw her taking several plates back to the kitchen. But even factoring that in, it really was taking too long for her to get to us, and another waitress (hostess?) came to take a drink order for our table to "help her out."
When she did come to our table, she didn't really pay much attention to our table. Rushing, perhaps? Distracted? Uninterested? Even when she asked about dessert, my mom said what she wanted, and the waitress replied with, "I'll get a dessert menu."
I can understand the menu may be for others at the table to look at and opt to order from, but the way she said it came off sounding like she ignored my mother's order. I found this annoying at best.
I prefer to think of incidents like this being isolated one-offs; the waitress could have been overloaded, perhaps it was a bad night, perhaps the kitchen was causing problems. I don't know. My opinion usually goes full-anger if there's a repeated pattern, and since this was a one-time visit I can't tell if there's a pattern against which to judge. So this one visit marks the service as "annoyingly slow."
The last thing to mention would be the gift shop. It, too, carries the Gothic horror theme, decorated with items such as traveling trunks stamped with the White Star line (Titanic history, anyone?) and Dr. Jekyll's name. The walls had bookshelves that doubled as hidden doors, probably to the haunted house attraction we didn't buy tickets to. There were a number of interesting Halloween-esque trinkets available, with discounts for members and some items marked for purchase by members-only.
Overall it was a good experience; I'd have to say that the entire meal was meant to be an experience, rather than just a meal. It was definitely a fitting prep to the days leading up to Halloween.
Friday, October 25, 2013
I Made a Podcast!
The blog is one obvious endeavor. I get to express myself into the great nothing; sure, few people will see it, but it still exists. It is something that in a way affirms I was here. And I had opinions. I'm very full of those. And what are blogs for if not to tell the world what you think and why you think you're right?
Another side project is programming. I've always had a partial attraction to it; I want to create applications, websites, things that are useful. Yet I've been held back, ironically, by my lack of knowledge. I end up feeling inadequate, and quite frankly, too stupid to actually accomplish something. I've been making tiny steps with my current skunkworks application project but keep questioning myself the entire time, feeling that if a "professional" programmer saw it he or she would wonder what kind of neophyte baboon could have created such spaghettified crud, let alone something that looked like that and still compiled.
Which re-reading I suppose is somewhat ironic, since the project I plan to take up after this one is going to be based on Ruby, which doesn't compile. But that's besides the point.
A third project I've toyed with starting is podcasting. There was a time I thought of trying my hand at being on radio; after all, I'm opinionated, I'd like to think I'm reasonably articulate, and if you look at pinheads like Sean Hannity and Bill O'Reilly, they're proof that intelligence is not actually required to do well when broadcasting your opinion.
But like so many projects, this was kind of a daydream. The company I'm working for puts out a podcast on an irregular schedule, but I eagerly listen to it as it's being recorded. I had a vague idea of what was involved in creating a podcast and setting it up to distribute, but never fully dove into the steps.
My manager periodically checks in asking how the job is going and what is on my mind. One day I brought up the idea of podcasting, and he said he'd help out.
Rather than keep waiting until the "perfect moment" to do it, I borrowed a page from the "how to write a book" podcasts I've listened to in the past. I just did it.
I set a time to record with Pete, he set up some software to record a Google Hangout, we came up with a topic...a theme, really...presentations. Because part of the goal of doing the podcasts was to improve public speaking skills. And we talked for about half an hour about presentations.
A little cleaning, adding some intro and outro music, and after much fiddling with establishing accounts, I managed to get uploaded and configured as a podcast!
There's not much of an audience. You can count the downloads on two hands, actually. But that's kind of freeing at the moment because there's not much chance of anyone complaining about how offended they are. And at the moment we're trying to establish what kind of podcast it is. Geeking After Dark is basically "geeks discussing their lives," which could be about just about anything. Because we're geeks. And we're talking about our lives and stuff that interests us.
In addition I'll be working to get some of our coworkers recorded, to hone interview skills. There's room for improvement...but to be honest, as first shows go, I think the first one wasn't all that bad.
I'm a little nervous about advertising it with only one episode on the feed. This one episode doesn't really define the whole planned series; it's...well, just one episode. Things are going to change, things will hopefully improve.
In the end, I did it. That's the important thing. It's not perfect. But I did it.
Like my blog...I'm not a great writer, but I'd like to think I'm improving. And for a long time, I didn't do this because I was afraid. I was afraid it wasn't good enough. That I wasn't good enough. After many months of blogging, I still have hardly any audience, and maybe that's a sign of my lack of skill. Or it's a sign of my lack of marketing prowess. But the important thing is I did it.
And my programming project. I have an almost crippling sense of inadequacy when it comes to m programming skill. And I'm a green newbie when it comes to programming...all the time I could have been creating things as a hobby were squandered on other things. Until I finally decided I should do something about it. And I did it. Well, I started it. It's a work in progress. The important thing is there is a project file on my hard drive that compiles. I did it.
And now I have a podcast. I don't have much in the way of validation that I'm doing something right. Or wrong. I just decided I wanted to market myself and my opinions. I wanted to do it. And now...I did it.
Cross something else off the bucket list.
If someone reading this blog happens to be curious, the podcast is Geeking After Dark. You can read about it at the Geeking After Dark blog, and follow us on Twitter. Or search for Geeking After Dark on iTunes.
Listen to us and leave comments on the blog! Constructive feedback is welcome!
Sunday, October 20, 2013
Hi! I Recommend This Site, Twitter!
The message consisted solely of, "Hi! I recommend this site <link>"
Of course that had an actual link embedded.
My first thought was that malware was hijacking her system or my parents had given permission to a third-party website or application to post to Twitter on their behalf. She's using a Macintosh, so while it is less common, it is still possible her system had malware hiding on it.
I emailed instructions to check and revoke third-party application access to my parent's Twitter account;
- Log into Twitter.com
- Click the gear icon in the upper right corner
- Click "settings" from the menu
- Click "Apps" from the left-hand menu list
- Review the applications and revoke access from anything you don't recognize
I verified with her that she had antivirus running (she did) and told her to run a check on her system.
A few hours later another Twitter DM appeared. "I advise to visit the link <link>"
This was followed by another link a few hours after that, the text of which more closely resembled the first message. It was at this point that it occurred to me my reflex was to assume the system was compromised; I had grown up in a computing period where the home computer ran applications, not "the cloud."
It appears that we've given up control of many of our services and accounts; we trust companies to keep our information safe. This was an example of when this trust goes awry.
The messages must have been originating from someone logged into the account from an unauthorized location; I emailed my parents and told them they needed to change the password on their Twitter account. I got an email back a relatively short time later that they were going to change it, and I haven't had another DM from their Twitter account.
I started searching around the Internet. Surely, if this is a spammer attack of significant size there must be some mention on the Internet about it, right? Maybe Twitter is even doing some work to isolate and block the spammers?
The results were disappointing. I found little, if anything, to go on. I actually found only one article that directly addressed the wave of spammer DM's and advised changing your password as a post-discovery fix.
Another article made mention in passing of this particular spammer attack, but primarily made reference that Twitter had changed something preventing DM's from using links to non-authorized URLS. The article went on to say that the URL blocks were actually acknowledged by Twitter to be a bug. Even so, the spammers were working around it by linking to other tweets (apparently that was working for them.)
Tuesday, October 15, 2013
Project Breaks
But still, I didn't like leaving it too long.
The truth is I've had a couple other things going on. This past weekend my wife came to the city and we spent three exhausting days running around New York Comic Con. Panels, cosplay, panels, shopping, and of course, some more panels. My wife went home with some gifts for my son, like a recent issue of Nightwing signed by Kyle Higgins and some t-shirts to show off at school.
She was ecstatic about having seen the cast of Walking Dead; it was probably the only TV-show panel that had the majority of the cast on stage, and they really seemed like awesome people.
This week the office is hosting our remote employees in the community, developer and systems administrator groups. That's a lot of people in our office space, pushing us to capacity and then some.
In yet another bit of news, just before my wife came to town, a coworker and I started recording a podcast. We had been discussing it and coming up with topics to use in the program, but kept putting it off. Finally I kind of made the decision to just up and do it; we recorded the day of our company town hall, held bi-weekly, so we could use that as a kind of reminder of when to record. It's not perfect by any means; we recorded on the cheap, using headset mics and recording over Google Hangouts (since we were remote and couldn't work in the same room.) We definitely could use better microphones, and we may have to experiment with audio processors to properly clean things up. But if we waited to get things just right we never would have ended up actually getting it done.
We recorded, he cleaned up the audio, and when I could sneak in some time here and there I worked on the album artwork and configuring a blog, the hosting account and the iTunes feed after doing some tiny post-editing on the MP3 file. I just got these things working; as I told my coworker, the programming side project I've been talking about was put on hiatus and I was hoping to get the podcast posted within a week of the recording, which I miraculously did, despite also telling him that I was going to try to get the podcast worked on over the weekend but realistically I wouldn't get much done over Comic Con weekend, as I knew it would be exhausting.
All of this comes down to the point of the post title...the need for breaks. Sometimes things come up and priorities shift. We all get the same 24 hours in a day, but there are times where the things we want to get done have to take a back burner.
The Month of the Busies isn't over yet. I have family coming next weekend in preparation for my birthday-when-it's-not-my-birthday. I'm not sure how much I can get done in that time. And of course this happens to be a birthday where I need to get my license renewed, meaning another trip back home in the near future. All of which tends to interfere with getting things done.
On the other hand, taking a break from my projects may mean returning to them with a renewed sense of purpose and energy. Plus, I'm experimenting with podcasting as an outlet for creativity. I'm not sure where it'll lead but it might feel rewarding. Breaks in routine can be both a source of anxiety ("I'm not getting anything done!") and source of perspective ("The world didn't end despite not having finished XYZ when I wanted to...and look what I made instead!")
I suppose I can chalk up several "me-time" projects now. The personal blog. The podcast. And the program. The biggest challenge will be scheduling them to fit into the same 24 hours that up until now I've been complaining about fitting only two projects into!
Tuesday, October 8, 2013
What Makes You a Better Programmer?
Every time I look at the lines of code I've written I question whether there was another way I should have done it a different way. Should this be in a subroutine by itself? Is there an easier way to do this? Am I missing something that would be obvious to an experienced programmer?
I'm not sure if the second-guessing is a symptom of learning or a symptom of my own lack of confidence. Perhaps it's a little bit of both.
What I've generally been doing is pushing the application to do what I want it to do, to a minimal degree, while making some small notes about things I should do later. Little things like actually checking if a network connection was made rather than assuming it got the expected responses the applicatoin needed, and not overwriting a file of cached data with an error message from the servers. Better error checking. Wiping test assertion and debug message boxes sprinkled into the code.
I'm trying to make something functional to the point of demonstration.
I'm trying to make scaffolding, a facade; something good enough that I can go back to smooth the rough edges.
This also means that I'm cutting corners. I didn't write a spec. Only after making significant progress to a working application did I stop and create a pseudo-spec of how I wanted it to work. By not putting in the planning I'm creating things on the fly, and so the application logic probably isn't as clean as it could be.
It feels like it's close do the "demonstration" status. But doing it the way I have...feels amateurish. I think I pictured a "true programmer" as not going through stages like this, just whipping out functional code from the get-go. They get an idea in mind of what they want, sit down, and just keep ripping through function after function until a shiny, properly functional application pops out of the compiler.
So how do I become better?
I've heard some say that you just get better by doing. Want to become a better programmer? Program!
I never really believed that. Not fully; I think it has merit to keep in practice by doing something, but only if you do it correctly. If you are doing something incorrectly, you're simply reinforcing doing it incorrectly.
I told my manager that I was working on a project to enhance my programming awesomeness and he seemed glad I was working on it. I didn't get into much detail on the project...I wanted to wait until I had something to show. I brought up looking at my old projects and being appalled at the sloppy coding.
"I hadn't even sanitized the input! Sure, it was an internal project, internal network, and the chances of something bad happening were slim, and I put the whole thing together in four months, but still...even in the notes for the project I acknowledged these shortcomings."
"Well, at least you knew of the problems."
Maybe part of being a better programmer is realizing the shortcomings in your program.
What are the hallmarks of becoming a better programmer? Recognizing issues with your programs? Being able to sling lines of code without a second thought and have it compile the first try? Simply spending time programming, programming, and programming some more? Or are there other things that make you better (and how do you measure the baseline for improvement?)
Wednesday, October 2, 2013
So You Resell Your Software, But Don't Support It?
I ran into an interesting problem recently that left me with a rather poor impression of a company. I won't name them...simply because you have to be on my "burn that ridge with napalm" list...but perhaps there are others that have run into similar situations.
This particular software is one we use every few weeks for a rather important company function. Upon launch, it checks for an update; this tale begins with one such update. The most important machine in the chain ran the update. The application launched.
Then it crashed.
Relaunch. Crash.
Restart. Log in. Launched, crashed.
Uninstalled the application. Re-ran the install. Launched, crashed.
Well, dammit.
Dual-booting saved us at this particular point, but afterwards I tasked myself with getting it working again as it should. After running through logs and searching for leftover cruft from previous install attempts, I was stymied.
Next step; Google. I was mildly surprised when searching for the product by name I had barely any appropriate hits. I should have realized this was a sign.
Next I went to the vendor's site and searched for their knowledge base. Instead of a repository of repair information, it was documentation for how-to's and tutorials. In fact I don't think I ever found a "solve your problems" list.
Maybe it was a corrupt installer. I looked for their downloads page, which only had a couple miscellaneous plugins available and were of absolutely zero use to me. At this point I'm thinking, "What the hell?"
Okay, next step, contact support. I despise phone use; email gives me a reference to go back to, and I can easily share what's transpired if I need someone else to take over. I located an email address and sent details of my issue. For some reason this was met with a reply from what looked like an out of office auto-reply from a company trainer. Are their tech people also the trainers?
Fortunately someone else replied from their company fairly soon after. We traded some messages before he said that there was an issue they were now tracking with that version, and asked if we could install the previous version.
"Sure! Where can I download it?"
He sent a link. I clicked it. "You must log in." Dammit.
Ummm..."register"...click.
Name...email...why do they require my mail address and phone number? I just want to download this bloody installer and be done with it!
Submitted the request, but instead of the usual "Check your email, hosebag" reply I got a page telling me they had to review my request. Wha?!
I emailed the tech what I ran into, and he replied that he asked that team to expedite the request but they couldn't find that we were eligible for support.
...wha? Keep in mind the software was put in to control a system in our new office that had literally just celebrated...that day...it's six month anniversary. We were actively using this system. I doubt we'd be out of any reasonable support window.
"Are you a reseller or did you get our software through a reseller? If so you'll need to contact them."
I was surprised. YOUR company name is on this. You have a potential fix for a release of software that looks like YOU broke. What exactly is the harm in giving me this solution?
I sent messages to the person that did the original installation and found that yes, we had acquired the software through a reseller. I contacted their support, summarizing my previous exchange. I got a message back with the older client attached along with a note that they were changing something on their side to revert to an older version of the software when updates were polled.
I installed the older client...and it worked.
So the original company apparently resells their software without rebranding, and the reseller acts as a gatekeeper for their clients' updates. I wonder how many requests they get when someone is trying to troubleshoot a problem and wasn't aware the install came from a reseller?
More to the point, why is their support information and client software behind a registration wall? As far as I know the software is useless without extra server sauce. It's certainly not important enough to lock it away. I just need a problem solved, and your name is attached. If you're doing it for marketing purposes, congratulations, you ticked me off enough to not want to talk to your salespeople because I just wanted to solve a pressing problem. Did I mention I hate arbitrary roadblocks to getting an otherwise simple task accomplished?
Here's the thing. When I have a problem, I just want it solved with minimum hassle. At the time of the original failure, I was pushing a critical deadline. Asking for more information for your spam list was not winning points with me (good luck sending mail to that office that may or may not exist at that address, by the way. It's a jerk thing to do, but it kept me from getting more irritated.) What a reasonable company would have done is worked to make the customer...who already associates your name with what was becoming a growing irritation...happy. Because, presumably, it was your code in the first place. Otherwise you're outsourcing your reputation.
Which is fine, I suppose, if the resellers are stellar in the first place. And the reseller here was minimal hassle, fortunately. It was just that I, coming into the situation, didn't realize I had to contact a third party to handle the issue.
"But what if the reseller had custom settings in their deployments, so the original company couldn't give you their Clint without breaking things?"
That's a reasonable reply. If I were in charge of that project, though, I'd still look for ways to protect my brand and make it easier on the end client. For example, skin the program with a theme for the reseller while relegating your software to a plugin or codec. If possible, register the software in a way that you know XYZ uses the software but it was purchased through reseller ABC - use a version code somewhere that you'll know that is from a particular reseller. I'd still be irritated, but it could save some time instead of tricking me into trying to register for another absurd paywall.
Last thought: I really hope while you're outsourcing your reputation, you at least have a lot of active communication between your tech support and the support departments of your resellers. I'd hate to imagine how irritating it would have been to be forced to have a drawn out back and forth with a third party reseller only to eventually discover your code was broken at the originating vendor.
I'd probably have named you in this post if that happened.
Friday, September 27, 2013
First Week of Programming Re-Introduction
I'm sneaky like that.
I originally wanted to work on a project using Ruby on Rails. I've been reading Why's Poignant Guide to Ruby during off-time and occasionally during lunch at work, but the practical hands-on project I've been working on is written in Visual Basic .NET.
Yeah, I know, Visual Basic. I already explained why in a previous blog entry.
What have I learned this first week?
I'm still re-familiarizing myself with details of how things work in VB and Visual Studio. I'm no doubt making some tasks harder than they need to be; a side effect of practical inexperience. Re-learning...not as bad as learning, but frustrating when you know you've done something before but just can't remember it.
It doesn't help that I'm not focused for periods of time on the project. I tend to work on it for an hour or two a day, after coming home from the office. I get home a little late, I watch something while having some dinner, then work on the project, go to bed later than I should, wake up, yawn, and wish I had gone to bed sooner. Repeat.
The last thing I really learned was that Joel Spolsky was right; write a spec. Or for a small one-person project, take the time to plan out what you're doing. I have been doing the seat-of-pants approach to this mini-project, primarily focusing on "here's what I want it to do, and to do that, I need it to do X,..." then I tried to create X. Then identify the next obstacle and work on that. I didn't know if I was really going in the right direction so much as I was creating a series of fixes that may or may not repeat functionality or at least overlap.
That's pretty much the project summary. A lot of re-familiarization and a hint of re-planning with a few drops of wishing I could dedicate more than an hour a night to it. Is this how most software projects work if it's not your day job? Because for me it gets just plain frustrating (in addition to the frustrations of running into logic problems and figuring out why something just doesn't work.)
Wednesday, September 25, 2013
Blogsy: Blogging on the Go
I enjoy blogging. I never claimed to to be great at it and I don't have a substantial number of readers, but I find the practice of writing to be cathartic. Sometimes it's even helpful, as I forget the keyboard shortcuts to applications like Screen and OH HOW HANDY I posted them on my blog.
I also find myself traveling around quite a bit. I probably find myself on a bus back to my home in PA once a month, and that bus trip is between three and four hours long.
Ugh.
Sometimes I fill the time with podcasts or reading. But other times I want to feel more productive. Writing a blog post entry scratches that itch nicely.
Of course there are a few problems.
I tried using the laptop. Being a bus, there really isn't a lot of room to get situated with a laptop, but I've managed to do it. The next obstacle I commonly encounter is internet access; I don't have a cellular hotspot device, my phone doesn't support tethering and even if it did, you're either unfamiliar with traveling through PA or wildly optimistic to think cell coverage would work without frequent drops. Some of the buses offer wifi, but they are still tethered to the cell network and prone to dropping out; that is, when they have wifi working at all.
My wife bought me an iPad Mini as an early birthday present. I thought, "It's small but not too small, I don't mind the keyboard, maybe there is an app to blog on the iPad..."
I thought there would be many. There weren't. The ones I did find weren't that great.
I stopped searching when I found Blogsy.
Blogsy worked with Blogger (required!), let me access photos on my iPad (handy!) and format my text (nice!).
Best feature for me: no Internet connection required (perfect!). Blog posts could be composed locally and uploaded later, meaning the crappy bus wifi wasn't an issue (unless I needed to research something or test links for a post...that got a little irritating, but was hardly Blogsy's fault.)
Another bonus: Blogsy can access many other sites to link content to your posts (when there's Internet access, of course.) The right side of my screenshot has an iconic display of services like YouTube, Facebook and Picasa in addition to the local photo storage.
Another feature some users will appreciate is access to the raw HTML with the swipe of some fingers. So far I've had to use it to tune the positioning of some tags for links, but if you like exact control over the appearance of your posts then this is a surprisingly handy feature to find in an iPad blog editor.
New users can be easily overwhelmed with the interface; Blogsy has PLENTY of documentation available as well as training videos and FAQ's, both on the website and linked within the app.
In my usage of Blogsy I've had two consistent issues. One, the publishing date setting doesn't seem to like to hold the date while I'm editing. It's FANTASTIC that I can still control when the post goes up, as I'm often queuing posts to appear over the next several days, but the Publish Date setting seems to like resetting to "Auto" instead of the specific date and time I set.
The second issue is the disappearance of my text behind the virtual keyboard as I'm typing. I'm not sure if that's a Blogsy thing or an iPad thing; can the app detect when the cursor is disappearing from view? I end up having to pause and scroll the page so I can review what I'm typing.
Feature requests? It would be nice to get some stats off the blog using Blogsy. For example, how many views has a particular post received? Perhaps the authors of the app want to focus on Blogsy as a posting editor more than a blog management platform, but when the app already has nice touches such as the word count I think statistics would be an equally nice touch.
Bottom line, if you enjoy blogging and occasionally want to write while at the park (as I am doing with his entry) or some other location where a laptop is a hindrance but your iPad is handy, give Blogsy a try. It's inexpensive and has more features than many bloggers would end up using while being compatible with every popular blog platform out there!
Friday, September 20, 2013
What's Wrong With Visual Basic?
There are a few things that the letter addresses. My background in the education system gives me a slightly different perspective, but I won't bother getting into the more popular issues it raised. It's already being repeated and rehashed online and all over. So much so she already issued a few updates and a followup post. It would be pointless to rehash the brogrammer culture, even though in this case it's more of a high-school moron culture.
The thing that kind of stood out to me was item number four on her list of suggestions for high school programming; I hope Ms. Endsley doesn't mind me borrowing from her blog here. Her suggestion read:
"Don't be boring and out-of-date. Visual Basic? Seriously?? Yes, I know I said I'm not writing to complain about your choice of programming languages, even though I'm still scratching my head on this one. The reason I mention your choice is that it doesn't help you make a good first impression on new programmers. I have no idea what my teen learned in your class because she wasn't excited about it. Without touching your minuscule class budget, you can offer a range of instruction with real-world applications. With resources like Codecademy, for example, students could try a variety of programming languages, or focus on ones they find interesting. Have you considered showing kids how to develop a phone app? Program a Raspberry Pi? Create a computer game? Build a website? Good grief, man — how were you even able to make programming boring"
First, the choice of programming link goes to an article where the author downplays learning VB because a search on Dice.com shows few jobs with VB experience in the title. Cobol is gone with the dinosaurs. The first thing to make me pause in his article was the statement that new programmer job-seekers need to focus on web development skills, then followed up stating that Java was more important than Javascript. I'm not a professional programmer, but something didn't quite add up there. I'd love to hear what people in the industry think.
Second, if you're going to do searches for programmer jobs, let's look to the pros at the StackOverflow Careers site (note: I work for these guys.) A search for "Visual Basic" turned up 263 jobs out of 1689 job listings, or about 15.5%. Not great, but it's still out there and in use.
StackOverflow.com has over 53,000 questions tagged "vb.net" out of 5,700,000. That's slightly under one percent. Yikes! On the other hand, the "ruby" tag has 82,400 questions carrying that tag. Java has 478,000, and Javascript has 443,500. Erlang, 3,700. Clojure, 5,800. Not quite the results I expected after reading the article from the Dice.com author.
Then again, you could use something like the TIOBE index for measuring language popularity (don't know why the author didn't use that to begin with...) Java was at the top, followed by C, C++, Objective-C, then PHP, and C#. Visual Basic was 7th. Then Python, Javascript, Ruby at 10th, and down at 13th place was VB.NET. The fact that "(Visual) Basic" was 7th while "Visual Basic .NET" was 13th would lead me to believe there are a lot of VB5 and VB6 applications out there that will continue to need maintenance.
Third, Rikki goes on to point out that her child...and I left out the huge amount of exposure to technology she described earlier in the post...was not excited about the class, and it's because VB doesn't make a good impression. Let's try a variety of languages!
Really? I'm not even sure how this would practically play out in a school setting. You have a teacher who probably isn't programming savvy. If he were, he'd probably be a programmer, not a teacher, considering the education environment today. But this is mere speculation. The programming classes I knew in the districts I worked were typically business or math teachers, primarily, and programming courses came from a course book. The teacher simply doesn't have time to work in a multitude of languages and have it not devolve into a nightmare in terms of keeping up with the student's work.
These are high schoolers. Most of them don't know anything about programming. And they are suddenly open to the choice of all these languages, as proposed...how would they know what's "good?" And it's not like they have four years to choose what they want to dabble in. They probably had to fit it into a semester. And actually accomplish something.
Which brings me to the next point...the first steps of learning the language is boring. Or a pain in the ass, depending on how you're wired. You can't do much with any language without understanding the basics (no pun intended); loops. If-then. While. Functions. Methods. Maybe getting into objects. You want to write a novel, but first have to understand what nouns and verbs are, and how to construct a sentence, then how to construct a paragraph, and somewhere along the way learn how to construct a narrative.
And some of these kids...these are just kids, most of them taking the course to fill in some credits in all probability...won't be able to quite grasp how loops work. Or a function. It'll be tough for them, if they even keep trying; often they give up, or just screw around in class, not caring that they're making it harder for other students who may want to actually learn.
If learning the programming concepts is hard, and learning the syntax is hard, that is still a bit of a cakewalk compared to learning the IDE. Visual Studio is complex. It's got tons of features that beginners won't even touch while making something that is still moderately useable. You could spend a week just exploring all the things Visual Studio brings to the table. But when you are looking for a professional job in programming, Visual Studio is the key tool behind any company using the Microsoft stack. Because of this, you can get tons of examples and help when you have a question.
But it is yet another item that takes time to learn, and for a beginner can get in the way. Not only are you learning concepts and the language, you have to learn to model in your head how event-driven programming works, and how your code ties to specific GUI elements on the form.
I've read that languages like Python and Ruby may be good for beginners. I used Python before; it was nice in many respects. But on the other hand, when learning concepts, you end up with a lot of programs that run at the command prompt. You learn some of the logic behind how to do simple tasks, and the command line is fine for that. Languages like Ruby and Python are great because you install them and can edit them from any text editor. Does that really excite kids though? Learning the concepts but not having anything fancy or graphical to show for it? Maybe you need to install a framework to enable a quick website creation. Then you get to introduce them not just to the language, but to the framework.
"I'm learning Ruby!"
"No, you're learning Rails, and was exposed to Ruby."
The fact is that in most schools, programming courses are little more than "install Visual Studio Express and follow the exercises." You can criticize the teacher if you want, but there are constraints in budgeting, time, and what the class can be expected to achieve in terms of getting projects done and graded. Nothing prevents the kids from learning more outside class time, and I'm really betting the class is just an introduction, not a training course for a career.
And what of a career with VB.NET? Is it really so horrible? Dot-NET applications are, as I recall, compiled down to a Common Intermediate Language, regardless of the syntax behind them. The Visual Studio family of languages ends up with CIL and are tied to those .NET installs you have to update on your home computer. Is there a performance difference if these kids used something like C# over VB?
I did a quick Google and discovered that I apparently had this question before. It even attracted an answer from Jon Skeet. Basically, no, it doesn't really matter once it is compiled down. You use the language whose syntax you're comfortable with and works for the job at hand.
A little more poking around the sites (for Programming and StackOverflow in the StackExchange network) seems to show that VB.NET has more bias against it not because it is necessarily inherently bad, but because of its heritage. Another irony to the "Why would you choose VB.NET to teach beginners?!," given that BASIC was meant for beginners. It's in the name. Beginners All-purpose Symbolic Instruction Code. While VB grew to something that little resembled the initial language, many professional programmers apparently came to hold disdain over those that would use VB and its ilk, because VB encouraged people who couldn't program to make programs. Similar to hatred towards AOL'ers in the early days of home Internet access because it brought the hopelessly non-technical into the realm of geeks.
That stigma apparently continues today.
I had used VB, among other languages. And as I previously alluded to in a blog post, I decided to make learning a new language a project. I started reading a guide on Ruby; mainly to immerse myself in a bit of the culture while starting to absorb some of the "Ruby way" of doing things. But Rikki's blog post kind of made me want to try something else to get into the beginner's programming mindset. I started working on a project in VB.NET. I'm still reading the guides for Ruby, but I want to see how far I can get on this other project.
I'm sure it wouldn't be a popular choice among real programmers. I'd be the target of disdain and derision, if any programmer read this and took the time to criticize my choices. The only ones I really fear showing anything to are my coworkers since they are working with C# and I'd actually value their opinions.
But I'm not a professional programmer. I don't have years of experience with full time programming. I'm coming to this with just enough experience to know terminology, the basics of a few languages, and eyes fresh enough to have a perspective professionals have probably lost. I suppose the end product will speak for itself, if there is one.
And if it sucks...which it probably will...maybe the next one will be better.
Also, if you are a programmer and have some insight as to why VB.NET is not something to subject new programmers to (using reasons that are rational), I'd love to hear them.