Thursday, June 8, 2006

Paylocity in Chicago is hiring for a Software Engineer

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/paylocity_in_chicago_is_hiring_for_a_software_engineer.htm]

If there's any sharp Software Engineers in the Chicago, IL area looking for a new job, my company, Paylocity (www.paylocity.com) is hiring. I've been at several good companies, and this is by far the best Software Development place I've personally seen. We're developing a .Net application for Payroll. Here are some of the perks:

  • Great Learning Opportunities: Working with cutting-edge .Net development (migrated to .Net 2.0 in November, 2005)
  • Work-Life Balance: Local software department - no travel. Dress code is casual. Office hours 8-5. We have laptops and can do extra work at home.
  • Working from home Tuesdays and Fridays.
  • Job Security: Smaller company (100 people total, 20 in software department), so we're too small to be outsourced, and privately owned (and owner refuses to sell), so we won't be sold.
  • Company has been profitable and grown every year (for all 8 years) - even during the IT crash we still grew.
  • Stable Group: 0% involuntary turn-over. Maybe 1 person voluntarily leaves each year.
  • Interesting work: There are separate IT and Internal development departments. Even within our department there are separate QA and Busines Analyst teams. Therefore you can focus on development.
  • Great, collaborative team. Average person has maybe 8 - 10 years experience. Team is large enough that you can specialize in areas that interest you (UI, Business Tier, Database, etc...), yet small enough to still get an interesting variety.

You can see an official description here.

If you're interested, just contact me at tims@paylocity.com.

Wednesday, June 7, 2006

Saturday, May 27, 2006

Continually learning better coding methods

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/continually_learning_better_coding_methods.htm]

Coding requires constant learning. Here are some ideas to help with that:

1 - Be prepared to spend not just time, but mental energy.

2 - Find ways to get input:

  • Other Opinions:
    • Code Reviews - both having people look at your code, and looking at other's code.
    • Read blogs
    • Read articles
    • Read the documentation. If you're using a collection, read the documentation to see how it suggests enumerating through or referencing it's items.
  • Experiment on your own code
  • Reflect back on your code
  • Ask yourself, "does this make sense?". If your own code doesn't make sense to you, it probably won't make sense to others.
  • Make sure that you're not re-inventing the wheel. Look for resuable components.

3 - Make the intent of your code clear so that others can help. If Bob doesn't know what you're trying to do, Bob can't easily help you.

  • Use smaller methods
  • Add helpful comments that explain intent, not just repeat the steps that the code is doing
  • Abstract out context and dependencies such that it's easier for people to understand what you really want.

There's obviously a lot more to say on this, I'll make some follow-up posts.

Thursday, May 18, 2006

How to send the Console output to a string

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_to_send_the_console_output_to_a_string.htm]

Sometimes when writing a tool or automated process, you want to read in the console output and send it to a string. From there, you can do whatever you want to it, such as parse for info. For example, a third-party tool (not necessarily even built with .Net) may display result information to the console, and you may want that info as part of some bigger process. The classes to do this reside in System.Diagnostics.


    public static string GetConsoleOutput(string strFileName, string strArguments)
    {

      ProcessStartInfo psi = new ProcessStartInfo();
      StringBuilder sb = new StringBuilder();
      try
      {
        psi.WindowStyle = ProcessWindowStyle.Hidden;
        //Need to include this for Executable version (appears not to be needed if UseShellExecute=true)
        psi.CreateNoWindow = true;   
        psi.FileName = strFileName;
        psi.Arguments = strArguments;
        psi.UseShellExecute = false;
        psi.RedirectStandardOutput = true;
        psi.RedirectStandardError = true;

        Process p = Process.Start(psi);

        sb.Append(p.StandardOutput.ReadToEnd());
        sb.Append(p.StandardError.ReadToEnd());

        p.WaitForExit();

      }
      catch (Exception ex)
      {
        sb.Append("\r\nPROCESS_ERROR:" + ex.ToString()); ;
      }
      return sb.ToString();

    }

Saturday, April 22, 2006

USNAF - Microsoft's National Architect Forum

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/usnaf__microsofts_national_architect_forum.htm]

I just got back from Microsoft's National Architect Forum in Vail, Colorado - and wow! To be at a conference with 200 top architects was humbling. There are several big things I saw:

  1. Microsoft is really maturing on Enterprise Architecture and agile processes.
  2. Paul Glen spoke (author of the great book Leading Geeks). A lot of good insight about how to manage geeks.
  3. There's a lot of good architects out there.

Perhaps the easiest thing to describe was Paul's closing speech. He had several good points from his book:

  • Geeks are different than other people because their productivity is based on thinking not behavior.
  • Power is useless with geeks because power only controls behavior, but Geeks deliver productivity via thought.
  • "Geekwork" is different than normal work. For example, in geekwork because technology moves so fast, the moment you step away from implementing code to become a manager, technology moves on. Therefore managers often know less about direct coding than the geeks they manage. In most other fields, managers know more than the people they manage.

Tuesday, March 28, 2006

Viewing the source of an Html File, even with the ContextMenu disabled

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/viewing_the_source_of_an_html_file_even_with_the_contextmenu.htm]

In IE, you can view the source of any file through either the context menu or tool bar. However, sometimes there are design reasons to disable or hide these. For example, you can prevent the content menu by putting this in the a script in the HTML body:

document.oncontextmenu=new Function("return false");

And you can hide toolbars by opening up a new window and passing in the appropriate options:

window.open(...);

However, even if a site does this, you can still view the source through the VS.Net debugger. Simply start debugging one of your own apps, then navigate to the target site in the address bar, and you'll see full source in the Script Explorer window.

Sunday, March 26, 2006

ASP.Net 2.0 Callbacks: Using callbacks to create a rich Web UI

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/aspnet_20_callbacks_using_callbacks_to_create_a_rich_web_ui.htm]

I just had an article on ASP.Net 2.0 Callbacks published in .Net DJ. It provides a basic intro, and some more advanced uses like handling multiple callbacks and passing multiple data values.