Well, after just over seven years of ongoing updates to the house, we’re sadly, but finally ready to move on to a new home. I posted several months ago about our new house in Plainfield, and as of last week we’ve listed our current place for sale.
If you’re interested in moving in to my old home in Carol Stream, please contact my realtor Sherry McGovern of J.W. Reedy Realty in Lombard, IL at +1 630-629-0016.
Here’s some more information on the home:
Make me an offer 🙂
This is not so much as a MSIE bug, but rather a non-standard “feature” (added in MSIE 5.5) that is often helpful when constructing websites that you try to build with valid XHTML and CSS. As all non-Microsoft browsers will see these as simple
HTML markup comments, it gives you the flexibility to deal with the inconsistencies and quicks in the various versions of MSIE. This is particularly important for the numerous changes introduced with MSIE7.
I’ve tested this with <style />, <script /> and <meta /> tags, but wouldn’t doubt that it works anywhere (but don’t see any typical situations for that!)
Some simple instructions:
- Start with an HTML comment
- Add the opening brackets, so it resembles <!–[if …]>
- Add the closing brackets too… <![endif]–> (don’t forget that extra less than and bang/exclamation point!)
- Add the versioning info, this should be pretty obvious, but i’ll list the most common ones.
IE 7 = MSIE7
IE 6 = MSIE6
IE 5.5000 = MSIE 5.5
- Some modifiers, (should you want a range of versions):
lt = Less Than
gt = Greater Than
- Make sure that the body content of the tag (which now resembles an HTML comment) is coded.
- That’s it, now be sure to test for expected behaviors!
<!–[if IE 6]>
/* <![CDATA[ */
/* ]]> */
<![endif]–><!–[if lt IE 5.5000]><style type=”text/css”>@import “/css/IE50Fixes.css”;</style><![endif]–>
<!–[if IE 5.5000]><style type=”text/css”>@import “/css/IE55Fixes.css”;</style><![endif]–>
<!–[if IE 6]><style type=”text/css”>@import “/css/IE60Fixes.css”;</style><![endif]–>
<!–[if IE 7]><style type=”text/css”>@import “/css/IE70Fixes.css”;</style><![endif]–>
<meta http-equiv=”imagetoolbar” content=”no” /><![endif]–>
“They” say that you can ‘learn a lot about a man, by the car he drives’…. just what do these say about me ?
- 1978 AMC Concord (Blue, 2 door, Straight-6)
- 1980 Chevrolet Citation (Black, 4 door, V6)
- 1988 Dodge Shadow (Red, 2 door, 4cyl)
- 1991 Oldsmobile Cutlass Calais (Silver, 4 door, ?)
- 1999 Dodge Avenger Sport (Shark Blue, 2 door, 2.5L V6).
- 2003 Honda Civic EX Sedan (Silver, 4 door, 4cyl.)
- 1991 Plymouth Acclaim LX (White, 4 door, 6cyl.)
- 2013 Honda CR-V EX AWD (Metallic, 4 door, 4cyl.)
What’s next, I’m not even sure, just drive fast and stay outta my way!
Occasionally, there comes a need to “look under the hood” of the code in a JAR file. While java is a compiled language, it isn’t quite machine code, but rather exists in a psuedo-code form to be used by the Java Virtual Machine’s JIT (Just in Time) compiler.
A lot can be learned from looking at other source code, unfortunately when using decompiled code you don’t get the original variable names or javadoc, but you can often better understand the API’s and performance issues in particular code.
I’m personally fond of DJ Decompiler, but I list several here for your use:
In my “day job” I do lot’s of code reviews. I’m a big fan of Agile Programming and JUnits, recently I was introduced to the world of code coverage tools available (for free!) to Java developers.
IMHO, here’s the three front-runners.
Personally I prefer the Eclipse integration provided by ECLEMMA, but I agree that no one tool is ever ‘best’ for all scenarios.
Some background on this topic if you are interested in learning more: