Hugoware

The product of a web developer with a little too much caffeine

Posts Tagged ‘Development

jsshell – Reputable Software??

with 2 comments

Yes, it seems impossible so I took a screenshot. My little jsshell project has made it onto a pretty ‘notable’ list of Google extensions.

If you don’t know what jsshell then you might watch the introduction screencast.

Well… yeah, it isn’t spelled correctly… but I promise it is the same one.

In any case, you can check out the list on the Google site for yourself and possibly pick up some of the other awesome plugins while you’re at it. Don’t wait too long since it is only a matter of time before they realize their mistake 🙂

So, what better way to celebrate than to go ahead and open-source the code?

As usual, you’ll find my code out on git-hub, since its, ya’know, awesome… GitHub that is…

[Source Code]
http://github.com/hugoware/jsshell

Advertisements

Written by hugoware

June 28, 2010 at 10:56 pm

Autocomplete? Yeah, But How?

leave a comment »

Unless you’re really hardcore you probably use an IDE with some sort of autocomplete feature. It doesn’t have to be the super charged intellisense you find in Visual Studio – It could be as simple as the autocomplete feature in Notepad++ (which I love by the way…)

In any case, I got to wondering today – How do other people use their autocomplete features?

Best I could figure there was probably about 4 different ways you could approach using autocomplete…

  1. Type just long enough to see the item you want and then use the arrow keys to correct item.
  2. Keep typing, regardless of when it appears on the list, until it becomes the selected item.
  3. Use both pretty much equally.
  4. Auto complete is for noobs

Yeah, it isn’t a very deep, through provoking sort of question but it is somewhat interesting to think about. Maybe there is some sort of deeper psychological meaning behind our choices… or not…

[Poll] : So, how do you use your autocomplete feature?

Written by hugoware

June 24, 2010 at 9:40 pm

Stop, Think, Fix Errors… (Repeat!)

with 2 comments

“Don’t change your code unless you know how it will fix your problem”. If I had to pick a quote to put a ‘squiggly line and my name’ next to, then this would be it.

I’ve seen developers stare blankly at an exception message, comment out a line of code or two and then try and run their code again hoping for the best.

This, of course, rarely fixes anything. Quite often the line of the error message has little to do with the actual problem. Instead, this introduces new errors into your code and causes the problem to take longer to resolve.

Even if you guess and make an exception message go away you still don’t know what caused the error to begin with. Instead, you have a new error that is quietly causing problems and is now much harder to find. They might be ugly, but exception messages are the easiest errors to fix… well, after compiler errors that is…

So, how can you “know” your change will fix the problem? Here are some of the recommendations I make to other developers.

Stop and Think… Carefully

The bug isn’t going anywhere and each time you guess incorrectly you add a new error to your code.

It seems like such a silly thing to even mention, but I’ve seen plenty of developers take a cursory glance at an exception message and then just start changing stuff. It doesn’t even matter if you’re in a “break-fix” situation – you should always carefully consider the problem before changing your code.

Read the error, start following up the stack and think about what could cause this result. Think about the conditions that would cause the error or how you could force the error to happen again.

If you don’t know why your change will fix the code then you aren’t fixing anything.

Understand the Debugger

You don’t need to know what a memory dump is for or how read binary manually to use debugger. Just simply understanding how to set break points and stepping into, over and out of code will probably cover 99% of the problems you encounter.

It might seem daunting at first but don’t ignore the debugger because logging or message boxes are easier to write. Once you get a hang of it, the debugger will most likely become the greatest tool in your future bug squashing adventures.

Isolate and Resolve the Specific Problem

It can be difficult at times to figure out why a section of code doesn’t work when it sits in the middle of a larger application. Sometimes its better to create an empty project and work with a smaller section of the program by itself.

For example, if you don’t understand how a part of your framework is supposed to behave, pull it into a separate program, for example a console application, and work with it until you are comfortable with the results. Then when you integrate your changes back into the main project you can be confident that any remaining errors aren’t part of the newly introduced code.

Look At Open Source Code

If you’ve written some code that is consistently causing problems then consider looking for a framework or open source project instead.

This isn’t a matter of being a good or bad developer. It certainly has nothing to do with being unable to figure out the problem for yourself. Quite simply, code that consistently has errors is probably a difficult problem.

Public frameworks and open source projects are typically owned by other developers that understand the problem better than others. They have taken the time to abstract away the specifics of a problem and build a clean API for other developers to use.

These developers are also typically eager to improve their code and will listen to feedback. Even if you don’t use their project there’s a good chance that you will learn something by simply reading their code.

To sum it up, don’t just change code and hope for the best. Stop, think, ask yourself how does this fix the problem?.

How do you approach fixing problems in your code?

Written by hugoware

June 23, 2010 at 12:02 am

Avoiding Confirmation Boxes

with one comment

One thing I try to avoid in interface design is unnecessary user interaction – Basically, asking the user for feedback when it isn’t needed. The area that probably bothers me the most are “confirmation boxes” – Especially those that block the entire application until you’ve clicked ‘OK’?

I’m not really sure why you see them so often in applications since I’m pretty sure that users and developers alike probably get tired of seeing them. Not only that, studies have shown that they are mostly ineffective, normally only earning a cursory glance before being dismissed.

So what can you do instead?

Don’t Confirm Success, Notify On Failure

Probably the easiest and quickest improvement to an application is to stop confirming when your application worked. How many times have you seen this pointless little window pop up?

Uh, yeah…

For the most part, a user should be able to assume that their “request completed successfully.” — Otherwise, why the heck did they buy your software to begin with?

Instead, pop up a modal dialog box if something goes wrong and their request didn’t work. This is a much better time to interfere with user work flow.

Allow Permanent Dismissal

New users of an application don’t mind confirmation boxes as much since they are still poking around and trying to figure out what everything does. But after the 10th or 15th time the ‘your request has been completed!’ message is starting to wear on them.

Sure, it was helpful at first but now that they know the expected behavior, the additional confirmation is an annoying extra click.

Ah, now that is better. I’m confident using this part of the program – stop bugging me!

Even Better – Don’t Confirm, Make It Easy To Undo

Remember the computer before the undo button? It was painful and frustrating, but then one day like magic we could fix our silly fat-finger mistakes – Genius!

What about the Internet before the undo button? Oh… wait. The ‘undo’ button is actually still pretty uncommon in web applications. Of course, web applications aren’t the only area that this applies – but it is still possible to make it happen. GMail is a great example of how this applies to any application – including the web.

The message explains what happened and gives immediate actions for the two most probably user responses – “What the heck did I just do?” and “Oh snap, I didn’t mean to delete that!”.

Use Visual Indicators As Confirmation

Visual indicators work well as additional confirmations. If you make it clear enough what a user is about to do then normally you can avoid a confirmation box.

Red highlights, short and clear sentences, explanation of the final result – All of these items act as an additional confirmation for the user to understand the result of their action. To take it a step further, the text on the button OK would be even clearer if it said Delete (see how easy this is!)

It doesn’t take much to reduce, and in many case eliminate, the dialog boxes we pop up in our applications. You’ll be happier, your users will be happier — Heck, I’ll even be happier even if I never use your application.

What are ways you can use to limit the number of dialog boxes you use in your applications?

Woes With External Assemblies

leave a comment »

In all my years developing with .NET I haven’t ever had a situation that I needed to load an external library into my code at runtime. Normally, I simply add the reference to my project and I’m on my way. As it turns out it can be slightly tricky if you’re new to it.

I’m working on a project right now that is broken up into several pieces, one of which is a shared library that other external libraries use, specifically to inherit from a base class used by yet another part of the application. The shared class is actually referenced by each of the projects but one part of the application loads the assemblies in at runtime.

To summarize…

  1. SharedLibrary is referenced by MainApplication
  2. SharedLibrary is referenced by ExternalLibrary
  3. ExternalLibrary is loaded dynamically by MainApplication
  4. ExternalLibrary has classes that inherit from classes in SharedLibrary
  5. MainApplication needs to cast classes in ExternalLibrary into base class types found in SharedLibrary

So to illustrate what happens imagine two classes the abstract class ParentClass and the inheriting class ChildClass. This code made sense to me when I first typed it in but the results surprised me.

//create the instance
string path = @"d:\projects\libraries\exampleLibrary.dll";
object child = AppDomain.CurrentDomain
    .CreateInstanceFromAndUnwrap(path, "ExampleLibrary.ChildClass");
Type type = child.GetType();

//the details about the class
Console.WriteLine("Class is: {0}", child);
Console.WriteLine("Type Name: {0}", type.FullName);
Console.WriteLine("Load : {0}", type.Assembly.FullName);
Console.WriteLine("Ref  : {0}", typeof(ParentClass).Assembly.FullName);
Console.WriteLine("Is ChildClass  : {0}", child is ChildClass);
Console.WriteLine("Is ParentClass : {0}", child is ChildClass);
Console.WriteLine("Casting : {0}", child as ParentClass);

//the results
//Class is: ExampleLibrary.ChildClass
//Type Name: ExampleLibrary.ChildClass
//Load : ExampleLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
//Ref  : ExampleLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
//Is ChildClass  : False
//Is ParentClass : False
//Casting : <-- which is null

What the heck? Admittedly, I don’t know why this fails – If I had to guess it would have something to do… well… we will discuss it in a moment…

I ended up with the following solution which worked exactly the way I had hoped.

//load the assembly manually
string path = @"d:\projects\libraries\exampleLibrary.dll";
byte[] bytes = File.ReadAllBytes(path);
AppDomain.CurrentDomain.Load(bytes);

//create the instance
object child = AppDomain.CurrentDomain
    .CreateInstanceAndUnwrap("ExampleLibrary", "ExampleLibrary.ChildClass");
Type type = child.GetType();

//the details about the class
Console.WriteLine("Class is: {0}", child);
Console.WriteLine("Type Name: {0}", type.FullName);
Console.WriteLine("Load : {0}", type.Assembly.FullName);
Console.WriteLine("Ref  : {0}", typeof(ParentClass).Assembly.FullName);
Console.WriteLine("Is ChildClass  : {0}", child is ChildClass);
Console.WriteLine("Is ParentClass : {0}", child is ChildClass);
Console.WriteLine("Casting : {0}", child as ParentClass);

//the results
//Class is: ExampleLibrary.ChildClass
//Type Name: ExampleLibrary.ChildClass
//Load : ExampleLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
//Ref  : ExampleLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
//Is ChildClass  : True
//Is ParentClass : True
//Casting : ExampleLibrary.ChildClass

Hmm… Not what I was expecting…

Even still, the code might be working – but one thing I always tell other developers is “that’s great your code is working – now, why is it working?”

After poking around for a bit I noticed something that really should have been obvious from the beginning. Take a look at this code and you’ll see where I’m headed…

Console.WriteLine("Load : {0}", type.Assembly.Location);
Console.WriteLine("Ref  : {0}", typeof(ParentClass).Assembly.Location);

//Load : d:\projects\libraries\exampleLibrary.dll
//Ref  : d:\projects\application\bin\debug\exampleLibrary.dll

Oh… so maybe not exactly the same type after all… 😐

I suspect that by loading the bytes in directly took the whole ‘location’ thing out of picture. Of course, I need to read up on this some more before I’m positive but if any of you genius developers out there can confirm my theory then it would be greatly appreciated.

Written by hugoware

March 4, 2010 at 12:29 am

Programming – AKA: Paint By Number

with 7 comments

This last week has been pretty busy for me. I’ve been working on several projects at work, deadlines coming due, trying to get personal projects done, jLinq bugs fixed — it’s been a rough week.

I was excited a few weeks ago when the new developer was going to start. I was finally going to be able to spread out some of this work and get a little more time on my hands… or so I thought. As it turns out, this guy isn’t exactly what I was expecting. Despite my best efforts, I still ended up hiring someone with pretty much no background in programming. I went from already being maxed out to now spending between 20% to 30% of my time teaching the basics of programming… yeah – this is my fault.

But as bad as it sounds it really has actually helped me rediscover a programming rule that I thought I was still using but apparently had forgotten.

So, one of the first projects the guy had to do involved checking a directory for new files, creating a record of the file if it was found and then processing existing files to transform file types from one to another. Really, probably an hour long job at most but was really causing this guy some grief.

An Alternate Approach — Simplicity

Naturally, as a developer, the first thing I started trying to explain was how the code would work like checking file dates or creating an XmlSerializer to load and save files — none of which actually helped him solve his problem. After several frustrating whiteboarding sessions I came up with a new route — make it so simple it was impossible to mess it up!

I took a second pass at trying to get the guy started in the right direction. Instead, I opened a new class file for him and wrote something like this.

public class FileRecordSync {
    //snip...

    //This is a list of the files that the program has already detected
    //this is also where to add new files that are discovered
    public List<FileRecordEntry> CurrentFiles { get; private set; }

    //determine if this file should be processed or not
    public bool IsValidFileType(string path) {
        throw new NotImplementedException();
    }

    //check and see if this file exists in CurrentFiles or not
    public bool IsExistingFileEntry(string path) {
        throw new NotImplementedException();
    }

    //check to see if the modified date is greater than the logged modified date
    public bool IsFileEntryModified(FileRecordEntry entry) {
        throw new NotImplementedException();
    }

    //find the matching file in the CurrentFiles or return null if nothing was found
    public FileRecordEntry FindExistingEntry(string path) {
        throw new NotImplementedException();
    }

    //create a new FileRecordEntry from the path and add it to CurrentFiles
    public void AddNewFileRecordEntry(string path) {
        throw new NotImplementedException();
    }

    //set the file as expired to 
    public void MarkFileAsModified(FileRecordEntry entry) {
        throw new NotImplementedException();
    }

    //snip...
}

Granted, an experienced developer could place all of those functions into a single loop and it would still be readable but isn’t the code above the kind of code we should all be writing anyways? Simple, clear, straight-forward functions each with a specific purpose and nothing more?

Code like this manages complexity – he didn’t have to worry about how each of the functions were going to fit into the master plan but instead how to complete each of the functions.

You know what coding like this makes me think of – Paint by number! And when it comes to code complexity – that’s a VERY good thing.

paint-by-number

It’s hard to tell what that is a picture of looking at it now — but if you remain diligent and fill in each of the blanks with the correct color then before long you’re staring at a masterpiece (or maybe not — this picture looks like someone holding a gun in FPS view — but you get the idea :))!

When it was all said and done with, the loop that had caused so much grief was much easier to read – not just for him but easier for me to read as well!


public void ProcessFiles() {

    foreach(string file in Directory.GetFiles(folder)) {

        if (!this.IsValidFileType(file)) { continue; }

        if (this.IsExistingFileEntry(file) &&
            this.IsFileModified(file)) {
            FileEntryRecord entry= this.FindExistingFile(file);
            this.MarkFileAsModified(entry);

        }
        else {
            this.AddNewFileRecordEntry(file);

        }
    }

}

Even without comments, you can most likely figure out what this code does with only a cursory glance over it.

A Personal Reevaluation

Its hard to say when a developer abandons simplicity. I think a lot of us start out writing gigantic functions that do much more than they need to and then slowly realize how much easier our lives are if we create functions for specific jobs.

Ironically though, I think the smarter and more skilled we become, we begin to lose sight of what a “simple” function really is. Some of us can write a single lambda expression to create a ham-n-cheese sandwich with our eyes closed — a 20 to 30 line for loop can’t possibly be that difficult for us anymore!

I can’t deny that I would have pushed all that code into a single loop, used a handful of well named variables with a couple clear and useful comments and called it a day. But looking back on the final result I can say without a doubt that I’d rather go back and make changes to the new, simpler class — wouldn’t you say the same?

Written by hugoware

September 17, 2009 at 10:17 pm

New Hugoware.net Site

with 11 comments

For the longest time now Hugoware.net has basically been the home for jLinq. Lately, I’ve been working on a new version of my site — one that represents all of the stuff I do and not just one of my projects. After working on the site for about a week I’ve updated with a brand new look and grouped all of my projects together into one site.

I’d love to get some feedback — so use the ‘Contact Me’ section to tell me if you think something could be improved.


hugoware

And of course, there is my Twitter Bird (he’s open source as well :))

twit

There isn’t much to talk about with the new site. Basically it is an ASP.NET MVC site with personal information and projects on it.

However, I’m always interested in hearing feedback. If you think something about the site is missing or could be improved, please let me know!

Written by hugoware

August 14, 2009 at 2:53 am