More Semantics

Focusing on semantics instead of the technical has application beyond CSS.

Amazingly, a few hours after posting my last bit on Semantic HTML, a coworker noted the following in a code review:

Small lie:

.indent16px{ margin-left: 15px; }

I don’t like indent__px for classes like this – it seems too specific and easy to fall out of sync like this one did. It also seems redundant to name the class after the style its wrapping.

I really don’t like ‘SmallIndent’ for classes like this – it’s not immediately obvious what small means or how it compares to tiny, normal, large, etc.

Any ideas on what we should name classes similar to this?

Great insight!  Moving to semantic HTML, alternatives for cases like .indent16px would follow by answering, “Why should this be indented?” Here are some examples, but depending on the context you can probably come up with something better:

  • accreditation-report-subsection
  • content-under-header
  • subcontent

Semantic vs. Technical in Testing

This is very similar to conversations I’ve been having with our testing team lately as we’ve been exploring how to write automated UI tests.  A key principle we’ve been trying out is to distinguish between what needs to get done and how to get it done.  For example:

  • What: Delete the “bankers” security role.
  • How: Click the “roles” button, find the row in the table with the “bankers” text, click the “delete” icon, click “Ok” on the confirmation dialog, wait for the page to refresh, verify the row is gone.

In this scenario I’ve been calling the “What” the semantic or business meaning, and the “How” I’ve been calling the technical meaning.

This distinction is important for testing because if you don’t separate your semantic code from your technical code (sounds like SRP) then you end up with logic duplication from one test to another (and we want to be DRY).  This has a very practical effect on how easy it is to fix tests when the developers change the UI.

Back to CSS

When you name a CSS class, ask yourself, “Does this name describe the meaning of the content (the what – the semantics) or does it describe how I’m going to style it (the technical)?”

Posted in HTML, Programming | Leave a comment

Semantic HTML

There’s a lot of literature about “semantic HTML” on the web (here’s one person who writes about it a lot). The best short advice I know of to get jump-started on this topic is from a page on W3C.  I’ve pasted the content below – enjoy and be enlightened!  :)

Use class with semantics in mind.

Often people use class names like bluetext, or redborder. A much better way to name your classes is with the role a certain HTML element of that class has.

Good names don’t change

Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Good names

warning, important, downloadableImage and submenu are all good names. They describe what a certain element represents, and they are not likely to change. A warning will always remain a warning, no matter how much the look of the page changes.

Bad names

border4px, lighttext and prettybackground are examples of bad names. You might fatten that border to a whopping 5 pixels, or the background may look pretty old after a while, and not pretty at all. An advantage of using CSS is that you won’t have to change much in order to change the looks of your website. If you have to change all light text into dark text, and thus change all classes lighttext to darktext in all your HTML pages, you’re likely to miss a few.

Posted in HTML, Programming | Leave a comment

Paradigm Shift: from Request/Response to Publish/Subscribe

Since attending Udi’s ADSD class about a year and a half ago, the publish/subscribe pattern in general has been fascinating for me to consider at many levels.  In some ways it’s a fundamental shift in the way we program. When we’re kids we learn how to ride bikes, and from then on we just hop on any bike and ride it without even thinking. When we’re beginner programmers we learn how to call methods, and from then on that’s what we do – we write methods and we call them without even thinking about it.

The downside is that this creates dependencies all over the place. These dependencies rear their ugly head in a large project that is now in maintenance mode. Consider a system that accepts membership applications from end users – here is some pseudo code that describes a high-level communication between the Application System and the Payment System.

class ApplicationSystem {

   void SubmitApplication() {
      PaymentSystem.ChargeForApplication();
   }

}

Now the Application System is deeply tied to the Payment System, and has to know business logic about when to charge, which really should be the sole responsibility of the Payment System.  The business concern of paying for applications should be as decoupled as possible from the business concern of processing applications.  The Publish/Subscribe pattern allows this:

class ApplicationSystem {

   Sub SubmitApplication() {
      RaiseEvent("ApplicationSubmitted")
   }

}

Key point: The Application System no longer depends on the Payment System.  But the same functionality as before can be implemented if the payment system subscribes to the ApplicationSubmitted event.

Consider this: The business changes and decides that instead of charging users when they submit their application they want to charge upon approval of the application.

Request/Response Modification: Application System has to change quite a bit to call the right methods of the Payment System at the right time.

Publish/Subscribe Modification: Application System doesn’t change at all; Payment System listens for “ApplicationApproved” instead of “ApplicationSubmitted.”  Pub/sub FTW!

Bottom Line: Divide large systems into smaller subsystems, and when it comes to integration of these subsystems use a publish/subscribe pattern instead of a request/response pattern. It’ll turn your thinking on its head for a while, but the end result will be a more decoupled system that’s easier to maintain.

Posted in CQRS, DDD, Programming | Leave a comment

How to Teach Data Types

I received this email from Terry Palmer, an instructor of CIS at Mayville State University.  As a software development professional, the preparation of new graduates in this field for real world work provided by mainstream universities has often been very disappointing.  I’m excited about things things Terry has been doing with his CIS students to pass on applicable, work-ready skills.  If you or someone you know is considering going to college for a programming-related degree, you owe it to yourself to take a peek at Mayville State University.  Here’s an illustration Terry uses to impart the concept of “Data Types” to students who are brand new to programming:

I made a trip to Fargo last night to find some tangible things that will help illustrate data types and how they work.  After much browsing around Michaels and Hobby Lobby, here’s what I came up with:

Integer: a small round clear container that will hold pennies.  I chose pennies because we like to count money.  Number datatypes are all about counting and math.  So when I add the contents of one container to another (or both to a third container), the result is the total that ends up in that container.  Putting a white label on these containers where I can write the name of the variable would probably help illustrate further.  For multiply, I could fill a container with the same number of contents as many times as I’m multiplying.

String: I picked up some aluminum wire and some alpha numeric beads that will work much like a necklace.  This will illustrate that every character basically gets placed right next to the one before it.  This illustrates that a string is literally a string of chars.  To add strings, you take what is on one string and add it along side the next.  Or you could have a third wire and place the contents of both onto the third.  This would be a cool way to illustrate left, right, and mid functions on strings.

This should also illustrate the fact that in a strongly typed language, you can’t add an integer to a string because they are completely different animals.  You could show conversions back and forth by showing that the string “6″ on a necklace would actually have to become six pennies in a round container or vice versa.

Arrays: Arrays will be represented by sections of an egg carton.  So if I have an array of length 2, I would literally cut 2 connected sections off of an egg carton.  If this was an array of integers, then each section would hold a container of pennies.  If it is an array of strings, each section would hold a necklace.

Objects: I got a cheap fishing tackle box for this.  This would be helpful for illustrating that a textbox on a form is not simply the text that you see.  If you open that up, text is only one property of the textbox and maybe that would be a piece of white tape on the front with the textbox text written on front.  If you open it up, you see a bunch of compartments on the inside that are labeled with properties like size, id, width, height, etc.  In these labeled compartments you could use penny containers and necklaces to illustrate the data types of those properties.

I like the idea of illustrating the data types because for many students, data types are a major hang-up and are not able to confidently progress while these remain a mystery.  Hopefully these physical representations will go a long way toward building a firm foundation or understanding.  It really helps me to have a mental picture of what I’m doing, but if I have never seen anything physical that is like what I’m doing, it’s just fog.

I’ll keep you posted as to whether or not this works and what type of student it works for.

Posted in Programming, Programming for Kids | Leave a comment

CodeRush FTW: Reorder Attributes

Check out this code block within an ASP.NET forms application:

image

It’s quite wide, and the repetitive attributes that I mostly don’t care about are left-most.  It’d be nice to move the “runat” and “EmbedInDiv” attributes to the end of these tags.  Having “LabelText” first seems nice, right?

CodeRush has a “Reorder Attributes” refactoring, that looks like this:

image

And you can put it where you want using left and right arrows, like so:

image

It’s got a cute little animation and all, but I’m thinking, “Like I want to do that for each line!”  But then CodeRush surprised me in a good way:

image

See that “Target: 6 of 8″?  CodeRush says to itself, “It looks like Jason prefers his attributes in this new order.  Let’s see if he wants to make this same change to all similar elements.”  Nice!!!!!

Posted in CodeRush, Programming | Leave a comment

Looking back at life

My boss at Nexus Innovations, Bob Pope, passed along this material written by Adam Doynes of Branson, Missouri. He did personal research with men that he highly respected about looking back on life. It is an impressive list.

The question I asked these fifteen men was this, “What are three things you know now that you wish you knew when you were thirty?”

I was hoping that these men would share the folly they had experienced as leaders and in life, so that I might not repeat their mistakes.

The forty-five responses I received from these men were packed with wisdom, humility, and truth that struck me to the core. I printed them out, laminated them, and placed in my office where they serve as a daily reminder and encouragement to lead well in all areas of my life.

Learning from the mistakes of others will help me avoid my own mistakes and, therefore, be less likely to be “a fool who repeats his folly.” I took the list of forty-five responses and reduced it down to the top fifteen. Some of the men had similar answers, so I took one answer from each leader, so that the list was not repetitive.

  1. The most important person you can lead is yourself.
  2. Nothing is more valuable than relationships.
  3. Maximize the moments with your children.
  4. Listen — you will never find the pulse of your family or organization if you don’t learn to listen.
  5. Worrying is temporary atheism. Rid yourself of worry.
  6. Become a better steward of your financial resources through investments and wise decision-making. The older you get the more you’ll want to give away, being able to do so begins with the financial decisions you make today.
  7. Balance — the words “No” and “Not now” are empowering when accompanied with wisdom.
  8. Spend time reading and receiving the Truth every morning, because the world will only lie to you the rest of the day.
  9. Saying “I’m sorry,” when spoken from a genuine heart, has great healing power.
  10. Character should always trump talent.
  11. Retreat and Rest — if ships don’t come back to the harbor, they’ll eventually sink.
  12. Don’t stop learning — you’re not as smart as you think.
  13. Learn to value patience. You’re likely to learn more while you wait.
  14. Time management — without it time will control you.
  15. Develop authentic and deep relationships with men who will sharpen you and see through you.

I hope that for any of us that aspire to be great leaders, we can look at this list that was compiled by men in their 50s, 60s, 70s, and even 80s, and learn from their lives well-lived. May we heed their wisdom as to prevent folly in our endeavors to become better spouses, parents, and leaders.

Posted in Softer Skills | Leave a comment

Update a SQL table’s XML value to insert a node

Sometimes a snippet of example code is all that’s needed:

update MyTable
   set XmlColumn.modify('
      insert <Description>This is a description</Description>
      as last
      into (/xpath/to/parent)[1]
   ')
   where SomeValue = 'whatever'
Posted in CodeMinder, Programming, SQL, XML | Leave a comment

SQL Injection Joke (with a lesson)

At a recent team stand up meeting I passed along a joke I caught on twitter:

 

A SQL Injection walks into a bar, starts to quote something but stops, drops a table, then dashes out.

The joke is a good occasion to refresh our memories on SQL injection attacks.  Vulnerable SQL code looks like this:

public void GetCustomerByName(string name) { 

 string sql = "select * from Customer where Name = '" + name + "' order by Name"; 

 // code follows to execute this sql. 

}

This function is called by a user entering some text into a website textbox.  A user might enter Fred into the textbox, resulting in the following SQL runs against the database, and everything is fine:

 

select * from Customer where Name = 'Fred' order by Name 

 

If a hacker goes to this website and enters ‘; drop table Customer – then the following SQL runs against the database, and the hacker has probably broken the system and caused a lot of heartache for a lot of people:

 

select * from Customer where Name = ''; drop table Customer --' order by Name

This simple technique was used thousands of time in the previous decade to hack into countless big-name websites.

So the joke is funny because it highlights all the necessary parts to construct a SQL injection attack:

  • “starts to quote something”  You need a single quote to match up with the starting quote of the original SQL statement.
  • “drops a table”  One of the nastier things a hacker can do, but they could also put in their own select statement to try to get any data out of the database, or they could update their own record to elevate their privileges – tons of stuff they can do.
    • (For example, you could update the product description text on a site like Amazon.com to add some HTML that redirects the user to your own web page where their computer gets infected with a virus that allows the hacker to take control of your computer and use it in denial of service attacks against other websites and extort money from them.  This exact thing happens all the time, even today.)
  • “then dashes out”  A double dash is how you do comments in SQL, so this “comments out” the rest of the original SQL the developer had in.

The way to avoid adding sql injection vulnerabilities in your code is to not use string concatenation when building SQL statements.  Because SQL injection is so dangerous it’s usually appropriate to adopt a policy of “never use string concatenation to build a SQL statement.”  The following code is probably safe:

 

public void GetCustomerByName(string name) { 

 string sql = "select * from Customer where Name = @name order by Name"; 

 sqlCommand.AddParameter("@name", name); 

 // code follows to execute this sql. 

} 

ORMs we use, like NHibernate, also block sql injection attacks unless used in odd ways.

Posted in Programming, SQL | Leave a comment

What Makes a Team Smarter? More Women.

Though-provoking article at http://hbr.org/2011/06/defend-your-research-what-makes-a-team-smarter-more-women/ar/1

My two cents:

  • I think the results are less about gender differences and more about the value of soft skills.
    • But the gender difference makes a catchy title. I saw the title on my twitter feed and thought, “This I gotta see…”  :)
    • At the same time, it’s not a huge shocker that women tend to be better at these softer skills than men.
  • I would guess the value of soft skills is amplified in a group of strangers getting together for a few hours, compared with a typical work environment.
    • That is, it’s not a surprise that when you put a bunch of strangers together in a group, raw IQ has less of an impact on the group’s performance than ability to listen, sharing constructive criticism, having open minds, and not being autocratic.
  • Investing in soft skills, not just raw intelligence, is worthwhile for a company to do.
    • Thanks to my employer, and Lorie in particular, for the continual investment in us in this area!
Posted in Softer Skills | 1 Comment

My Regular Blogs and Podcasts

As a software development professional, I use blogs and podcasts to keep on top of what’s going on in this technical world.  Here are the ones I use most:

Podcasts

  1. .NET Rocks.  Good source of mainstream Microsoft-related stuff; about an hour of content twice a week.
  2. Hanselminutes.  Also .NET-oriented, but Scott’s not afraid to vary from the Microsoft mainstream.  About thirty minutes a week.
  3. Herding Code.  This is generally .NET-oriented, but the four guys who host this one definitely look at alternatives.  They’ll definitely ask the tough questions and dive heavily into technical details.  They put out a 60 to 75 minutes show roughly every couple weeks.
  4. Distributed Podcast.  Relatively new one (eight episodes so far) with very technical talks about messaging, CQRS, NoSQL, Event Stores, etc.
  5. Marketplace Tech Report.  Four minutes each weekday of what’s new in tech; not programming-related, but almost always relevant.
  6. Talking Shop Down Under.  An Australian host; I just listen sporadically to this one.
  7. This Developer’s Life.  A different sort of podcast that talks about aspects of a programmer’s life that are not so technical in nature.  I enjoy this one, but it’s not one that will tell you about the latest whose-it and whats-it in the industry.  It’ll lead you to reflect in other ways about life as a programmer, and life in general.

Blogs

My actual Google Reader list had 40-some blogs listed, but most of them put out content rarely.  Here are the ones I follow most closely, roughly in order that I would prioritize them.

  1. Udi Dahan – http://www.udidahan.com
  2. Uncle Bob’s Blog – http://cleancoder.posterous.com
  3. Ayende @ Rahien – http://ayende.com/blog/
  4. Jimmy Bogard’s Blog – http://lostechies.com/jimmybogard
  5. Scott Hanselman’s Computer Zen – http://www.hanselman.com/blog/
  6. ScottGu’s Blog http://weblogs.asp.net/scottgu
  7. CodeBetter.Com – http://codebetter.com
  8. {codesqueeze} – http://www.codesqueeze.com (Max has fallen off the radar since starting his own business – go figure :)
Posted in Programming | Leave a comment