Thursday, December 11, 2014

Samsung Ativ S phone constant reboot loop problem

Problems and Symptoms

So sometime yesterday, one of my Ativ S phones shut off, and started buzzing periodically every few seconds. Interestingly, when attempting a hard reset, the phone would actually make it to the swipe screen, but then reboot after a few seconds.

The reason, I determined, was that the power button was stuck. This makes the phone constantly reboot, and therefore vibrate. Occasionally the splash screen is visible. Attempting to hard reset (volume down+power) or enter download mode (volume up+power+camera) allows the phone to boot temporarily, because it bypasses the normal power button functionality. However, hard resetting won’t work, because one must release the power button to do a hard reset.

As I understand it, this is endemic to Samsung phones generally. They should put some effort into correcting this.

I contacted Microsoft, Samsung, and Rogers (the carrier). None of them were any help. They had no idea what was going on.

(Hacky) Solution

Ultimately, this is a mechanical problem. The switch will feel normal.

There is no need to hard reset the phone. This would be a waste of time.

Rather, the switch needs to be cleaned or replaced. I expect anyone skilled with soldering could replace the switch, so if you cannot clean it, you may need to go this route. Perhaps an electronics repair shop can fix it.

However, I did not need to replace the switch. Here is how I got mine working.

1. Watch these videos. The first explains how to take apart the phone. I only needed to take it apart to get at the underside of the motherboard. You can skip pulling the switch covers out, for example.

This video describes the problem.

(Picture obtained from ebay)

The power switch is the top-left switch in the above image.

2. Once I had the phone apart, I used these two tools. I cleaned out the switch as best I could (without compressed air or rubbing alcohol, bother of which would have been better).


I used the pry tool (on the right) to wiggle the switch in its housing.

Then, I used the plyers to press the switch, and with quite a bit of force. It wasn’t until I applied a lot of force to the switch that it worked. I was able to do this without actually removing the motherboard, which was nice, because it made it easier to test (since I could just put the battery back in).

Comments on the video above indicate that others have had a similar experience.

Anyway, after doing so, my phone starts up, and works fine again. No hard reset. Just some force on the power switch.

Sunday, October 21, 2012

Source Code Commenting?

A little history

Over the years, my view on commenting source code has changed substantially. As an immature developer, I believed that it was worthwhile to comment the code in such a way as you could tell what the code was doing simply by reading the comments. This was my philosophy, and I followed in judiciously.

Why I changed (grew up?!)

There are two major problems with this.

1. Change.

Changes to the source require changes to the comments.

But this, despite what some would say about ‘don’t be lazy and just update the comments’, is much more difficult than simply ‘updating them’.

The real issue is that comments are written in a human context-dependent language.

Think about this for a minute. Here some rudimentary linguistics is quite helpful (and not of the nonsensical Derrida variety).

So what is the issue? The problem here is that meaning is found at the discourse level in human languages. Paragraphs are the real substantial unit of meaning. This means that changes to such commenting are vastly more involved than even changes to their source code. It is like rewriting a paper after changing the thesis, or major point. It isn’t easy to make it coherent.

2. Code can be expressive.

This is nothing new, of course (cf. Bob Martin’s Clean Code). Really, I have become increasingly convinced that anything that can be expressed in code should be. And that really covers almost all of it. We have human-readable languages for just this reason.

One caution come to mind, however: Brevity. Be as brief as reasonably possible. That is, don’t write excessively long camel-case names. Not because it is wrong per se, but because they become hard to read, thus negating their purpose. Use the context of the code. Interestingly, this runs into the same tension as point (1) above, since you begin to have “discourse level” interdependencies in the code.

The problem is that you cannot include all the surrounding levels of abstraction in the function name. If you do, it becomes too cumbersome to be realistically maintainable. However, this runs into the tension of context-dependent function names.

The key here is to make sure that every name actually exists at one level of abstraction, in my view, and to make sure that you’re applying dependency inversion judiciously. Then you can have sufficiently long names that don’t get either too cluttered, or so obscure as to be useless.

Work to become more expressive with English. Learn how to compress thoughts. Here’s a way to practice this. Write a five page essay on some topic, and then try to say the same thing in three pages.

With that said, where do I think we need comments?

The first thing that comes to mind is APIs. But I want to suggest that this is a red herring. APIs need commenting for a particular reason, in my view: Leaky abstractions.

’m beginning to wonder if this category couldn’t encompass all necessary commenting. The very nature of a leaky abstraction is, bearing with my tautological explanation, that an underlying, concealed, abstracted implementation can or will affect the behavior of the abstraction in a way that is not obvious at that level of abstraction.

So if I have two phones, and one of them is a cell-phone, and the other a sat-phone, the former will work in tunnels (most of the time), but the latter will certainly not. The underlying implementations leak through and affect the usage and behavior of a potentially common user interface.

You need to understand something about the implementation to know whether you can have a crucial call when you’re about to go underground for a while.
This is where comments are truly useful.

Of course, if we take any class or API, it may not be obvious how one should go about using the functionality; e.g. What do I call first?

However, I think that well-written tests are far better than commenting here. Why not ship your acceptance tests with your product? They should be human-readable, and they aren’t just an instruction manual. They are “examples” and “instructions” that actually self-verify. This can’t but help everyone involved.
Happy engineering!

Monday, October 1, 2012

The Zenbook Prime (UX31A): A stunning product with a few significant flaws

(Note: I have also posted this review here).
This UX31A is a beautiful machine. Note that the R7202F is a UX31A-1AR4. It is roughly akin to a DB71, but it lacks a TPM, and has Windows Home Premium. It has an i7 1.9 GHx, dual core, quad-thread processor.
It looks far sharper than any Apple (in my view), and its construction is solid. It is light, sturdy, and it runs cool (the CPU runs at around 40 Celsius under normal conditions, and all the warmth is centre, above the keyboard). The IPS display is beautiful, and is perfectly visible in direct sunlight. Its brightness vastly exceeds other machines in its class. It is simply the best display in its class, bar none. The colours are incredible. The audio quality seemed quite good to me, though I'm no audio expert.
This machine has DDR3-1600, not 1333, as posted in many descriptions (I confirmed that it is dual channel @ 800 MHz). The one I received came with a Sandisk SSD (more on this later).
The battery life ranged from 5 hours (full bright, wifi on, backlit keyboard on) to 9-10 hours (low bright, wifi off, backlight off).
On the negative side:
1. The screen has some backlight bleeding. This is common on IPS screens, but if you need perfect blacks and watch a lot of movies on it, you might notice it. It isn't visible in normal use. Mine bled on the bottom right rather noticeably on a full black screen. This isn't a big deal for me. It is a shame, though.
2. The keyboard seems to miss keystrokes now and then. I don't think this was just me; other ASUS users encountered this on their machines. It occurs when typing very quickly. However, the keyboard is otherwise nice to use.
[Note that my second UX31A was much better on this point.]
3. The touchpad is unusable out of the box. The latest beta driver on the ASUS site gets it working well enough. You may need to disable tap to click as well; this is commonly an irritation on touchpads, because you can 'click' with your palm while typing. Note that if you need more configuration of your touchpad, Samsung has a driver which will run on the Zenbook Prime's touchpad, which also corrects the issues.

[Edit: Do not install the 1.0.32 driver, as it is about as bad as it gets -- it doesn't correctly reject palm contact, and it does reject normal finger contact. It is next to unusable. ASUS ought to try out their software before the ship it. The 1.0.26 beta driver works well enough.]

4. The unit I received would randomly shut down a few minutes out of sleep, every once in a while. This wasn't a bluescreen. There is no data in the Windows logs about the shutdown. Odds are, the machine lost power somehow. It happens whether the notebook is plugged in or not. This is a serious problem.
[See here.]
5. The Sandisk SSD is slow in small reads and writes. As in, it is terrible (4 MB/sec in some cases). I confirmed this myself. The alternative AData drive that comes in this laptop when there is stock is reportedly much better. That said, the computer ran fast. Most would probably not notice this.
6. There is too much Junkware on it. I removed the Trendmicro trial, the ASUS cloud stuff, and a few other trials. Just install Microsoft Security Essentials and be done with. When the antivirus makers can produce software that doesn't act like the malware they try to stop, we can use it.
Overall, this was a really nice machine. Some of those flaws are bad, but hopefully ASUS works them out soon.
I would have given this full marks for quality, except for the keyboard, mouse, and shutdown issue.

Zenbook Prime and the Unexpected Shutdown Problem

Problem Description

Zenbook Prime ( UX31A) users may notice the computer occasionally turning off without warning. The shutdown is unexpected, sudden, and there is no blue screen / stop code in Windows.
Users will find an event similar to the following in the Windows event log:
Log Name: System
Source: Microsoft-Windows-Kernel-Power
Date: 9/26/2012 12:10:38 PM
Event ID: 41
Task Category: (63)
Level: Critical
Keywords: (2)
Computer: BLAH
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.
This is a common problem with Zenbook Primes, and it has been for months. There is no software that can bypass the Windows shutdown process. The unit is losing power suddenly. ASUS has not found a solution, and I doubt that they are trying all that hard.
This happens whether the battery is charged, and whether it is plugged in or not. It is rare (my machine did it once in two weeks).
Notably, on a previous UX31A (this is my second; I returned the first on account of this problem), it did it twice in two weeks. So I bought two separate UX31A’s, both with the problem. What are the odds? Quite good, if it is a universal, systematic problem, which I suspect that it is.

Specific Observations

I have consistently noticed that the problem (twice on the other UX31A, once on this one), happens within about 5 minutes of waking from sleep. This one happened at pretty much exactly 4 minutes after waking.
The previous system shutdown at 11:47:44 AM on ‎9/‎26/‎2012 was unexpected.
The system resumed from sleep at: 9/26/2012 11:43:45 AM
This, I think, is telling. I suspect it has to do with power regulation coming out of sleep.

Attempted Workaround

The Ubuntu guys have said this about sudden shutdowns - "RC6 on and Intel IOMMU off."
Status: Specific issue noted above may be safely ignored.
Intel RC6 causes sudden shutdowns (Solved)
Kernel developers are aware and working on an issue with DMAR+RC6.
However, Zenbboks experience sudden shutdowns with RC6 on and Intel IOMMU off.
The most stable configuration is to enable semaphores and turn off VTd in BIOS, see above.
However, this needs to be properly fixed in the kernel once RC6 gets enabled by default.
I have disabled VT-d in the BIOS, along with Intel’s shutdown power management. I have not yet seen the shutdown problem. Note that you don’t need VT-d, as it is a virtualization technology, and it is doubtful that most people will use that on an ultrabook with 4GB of RAM.
Zenbook users who have the shutdown problem – please try this, and let me know in the comments if you still see the shutdown problem.


Honestly, ASUS should have a public statement on their website indicating that it is a known problem, and explaining that they are working to fix it. Their boast of reliability is quite questionable at this point. That, and their service is just wretched. Their website doesn’t work well, their live chat doesn’t work at all (for me), they take too long to reply, and an RMA will take your laptop away for weeks on end. It really is unacceptable. But ASUS doesn’t ‘get it’, and that’s why they keep doing this.
This expresses the issue well:
My overall conclusions with this experience are that if I need customer service, calling the telephone service line is my best bet to get adequate and prompt help. Apparently customer service representatives must go through a list of set actions (resulting in multiple callbacks) before an RMA will be issued. Any sort of online technical support (e-mail or chat) seems useless and unhelpful. Most of the phone representatives seem friendly and helpful.
The laptop RMA service is performed within an adequate time frame (2 weeks, taking into account 6-8 days total for shipping to and from the service center), although the quality control of products leaving the service center seems subpar (did they really check that my laptop was fixed before sending it back to me?).
ASUS products still have a ways to go in terms of quality check prior to product shipment to match up to Apple standards. To be honest, as much as I like the Zenbook and PC’s, I’m not sure I would buy another $1000 laptop from ASUS again after this. It seems absurd that for a brand new laptop, I have to go through numerous phone calls and a month or more of back and forth before things are back to the way they should have been when I first purchased the laptop (let’s hope it stays that way).
Wake up, ASUS!

[Edit: Please read the comments. This approach does not seem to work.]

[Edit: It seems that disconnecting and reconnecting the battery has had some success for various Zenbook users. Note that this will void the warranty (which is nothing other than absurd, but be warned).]

[Edit: Perhaps this is an easier trick than reconnecting the battery? Asus tech recommended one commentator "disconnect the power cord and press the power button for 30 seconds, for a battery reset" and then plug it in and let it fully charge.]

Wednesday, October 28, 2009

Viewstate, Composite Controls, and Event handlers

I’ve seen a number of posts where individuals are finding that the events in their composite controls are not firing (i.e. the handlers for those events are not executed). I ran into this as well because I had certain sub-controls in a composite control which depended on viewstate for their existence. I was using parameters in viewstate to rebuild certain controls – controls which could raise events. Also, the parameters of the raised events were used to determine which event-raising controls existed.

Of course, viewstate is not available until the Load event.

viewstate reloads after OnInit and before the Load event. Because of this, viewstate will never be available in the OnInit phase. Any code that depends on viewstate must execute after viewstate is loaded. You must code your page around this requirement.

Now, that’s because the TrackViewState method is responsible for initializing view state, and it takes place after the OnInit is executed and before the OnLoad method.

The TrackViewState method executes immediately after initialization and marks the beginning of ViewState processing, and state tracking, in the control life cycle.

Anything done before TrackViewState will not come from viewstate, or be persisted to viewstate. As for the Load Event:

The Load event should be quite familiar to you, because we have leveraged this convenient location for common page code in our web forms in previous examples. It is a handy place to put page initialization logic, because you are guaranteed that all controls in the Page’s control tree are created and all state-loading mechanisms have restored each control’s state back to where it was at the end of the previous request/ response page round-trip. This event also occurs before any controls in the Page’s control tree fire their specific events resulting from value changes in postback data. To customize control behavior in this phase, override the OnLoad method.

Also, controls must be added as child controls in composite controls before their state can be persisted. See here:

However, what if the control tree hierarchy depends on view state?

Say we have a pager control, for which the properties are stored in view state. This pager initiates events which alter its own contents. If you click the last element, the pager needs to change in the next render. But, if you’re using a postback linkbutton, or any postback, a button with the same ID as the emitter needs to be recreated to raise and capture the event.

Barring the CompositeDataBoundControl, the place to insert the first recreation of the object tree is at the end of LoadViewState. MSDN reads at this point:

At the end of this phase, the ViewState property of a control is automatically populated as described in Maintaining State in a Control. A control can override the default implementation of the LoadViewState method to customize state restoration.

So the Viewstate is restored at the end of this method. This also happens BEFORE any postback is processed. You need the PREVIOUS control hierarchy built to process the linkbutton event, or it will just go missing. So it might look like this:

protected override void LoadViewState(object savedState)

   // We need all controls to be recreated in
   // the same state as the previous life-cycle so
   // that events can be processed. Those events
   // might require a change in the hierarchy, and
   // if so, the whole control hierarchy must be
   // regenerated before rendering.

This creates the control hierarchy, and restores the necessary parameters from view state (in this case, the pager might have the current page and the number of items on a page).

The event will bubble up from the linkbutton, and can now be intercepted.

But, the pager has changed, and so has the visible data. The control hierarchy can be rebuilt (again) in OnPreRender according to the new parameters.

protected override void OnPreRender(EventArgs e)
   if (doesControlHierarchyNeedToBeRecreated || Page.IsPostBack == false)
      // Recreate all child controls - something changed  
      // that makes the control hierarchy stale.


Notice that we also need to create it during the first GET operation, since the LoadViewState method is not called. The doesControlHierarchyNeedToBeRecreated boolean flag would be set in the event handler or OnBubbleEvent as triggered by the child controls in the pager or the listed data.

Hence, the flow is:

1. Init event (no viewstate available)

2. LoadViewState (viewstate restored by the end of this method; call the base).

3. At the end of LoadViewState, create the control hierarchy (i.e. CreateChildControls) and restore its state using the parameters in view state. The control hierarchy will now mirror the exact state at the point of the most recent rendering of the control.

4. The process postback data phase happens here. We must have the control hierarchy rebuilt by this point in the cycle.

5. OnLoad is triggered.

6. Event handling happens here. Catch any bubble events from the child controls. Since the control hierarchy has been created in step (3) exactly like the hierarchy that was rendered in the last cycle, from which the user triggered the event, ASP.NET will be able to find the originating control and fire the event. The viewstate parameters used in (3) can be updated here based on the events. If so, flag that the control hierarchy needs to be rebuilt, or the render will be a full cycle behind.

7. Prerender occurs. If an event in (5) has changed the output of the control, rebuild the control hierarchy as necessary at this point and restore its state.

This sequence enables you to (a) capture events raised using child controls in a composite control, (b) use view state to store the parameters that are used to construct the very child controls that can raise those events, and (c) update the rendered web control based on the latest state received through those child controls.

These three are otherwise in tension, since you need the controls to exist so that their events can be raised, yet those events themselves require that the controls be rebuilt. This requires the control hierarchy to be restored AFTER view state is populated but BEFORE the events are processed; i.e. in LoadViewState.

If there is a better way to deal with such scenarios (such as minimizing the amount of data you place in viewstate, using query strings, etc), I certainly want to hear it.

Various References

Control Building and ViewState Lesson for the Day

Composite Controls and the Missing View State

ASP.NET page lifecycle:

Control execution lifecycle:

Saturday, October 17, 2009

Abstract Tests and csUnit

I submitted a bug for csUnit a little while back which related to a problem in csUnit when attempting to execute abstract tests. Note that csUnit will crash (i.e. null reference exception) if the TestFixture attribute is applied to the base, and if the test method is not overridden or implemented in the subclass, it won’t execute.

Abstract tests are essential for writing contract tests, which are essential for verifying interface implementations, or rather, that classes all share a mutual understanding of how each collaborator is supposed to do its thing. And that’s essential for attaining an arbitrarily high confidence in the basic correctness of your code. I wanted to post the simplest work-around for this issue that I’ve managed to find.

Here’s the abstract test – this is where all the actual test code will be placed. That way, the same contract test will be performed on each implementation.

// NOTE: No TestFixture attribute!
public abstract class A_TestThingContract

   protected abstract I_Thing CreatePatient();

   public virtual void SetUp()

   public virtual void CleanUp()

   public virtual void testMethod(int i)
      // Do your testing here…

Here’s how the concrete implementation of the contract test might look:

public class TestThingContract : A_TestThingContract

   protected override I_Thing CreatePatient()
      return new Thing ();

   // Override each test method like so:
   public override void testMethod(int i)

The DataRow and Test attributes are inheritable, so they will be applied to the overridden method. This is nice because it means that you don’t have to duplicate them in the subclass.

At least there isn’t much in the way of duplication to work around these issues.

That’s it!

Tuesday, March 17, 2009

Automatically load a Visual Studio Extensibility package at IDE startup

I've been searching around for how one might cause a package to load upon IDE startup, even with no package tool window visible at IDE startup (having a tool window present in the IDE layout will cause the respective package to load). I’m posting this (a) for my own reference, (b) to keep this information in a single location, and (c) to assist any other VSX package developers who may run into this issue.

Setting a VSX Package to Auto-load using the Registry

This solution recently appeared here. Visual Studio 2008 will auto-load packages upon startup based on certain registry settings for the IDE. Therefore, in order to cause the package to load upon IDE startup, we need to add a reference for the package in the appropriate section of the Visual Studio’s registry tree:


Now, under this key, you’ll notice several keys.


Each of these corresponds to an IDE context (see LearnVSXNow! #13), and the name of each key corresponds to the context’s GUID. Basically, we need to add the reference to our package under the key for the context in which we want the package to load. For example, if we want the package to load upon startup, with no solution, we need to use the key for the NoSolution context. {ADFC4E64-0397-11D1-9F4E-00A0C911004F} is the GUID for the NoSolution context, so this is the key under which we need to place the reference to our project:


We need to add a DWORD entry with a value of 0 under this key that has the package GUID as the value name. For example, the following is an excerpt from a .reg file containing an exported key/value for a package that will load on startup:


Basically, all that we need to be do is add another entry (under HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ VisualStudio\ 9.0\ AutoLoadPackages\ {ADFC4E64-0397-11D1-9F4E-00A0C911004F}) that has the GUID of our package as the entry name.

In particular, we want this process to be automated. In other words, we want the installer for our package to make this change whenever the package is installed. Thankfully, this can be accomplished with ease using the setup project in your Visual Studio package solution.

1) Right-click on the setup project in the Solution Explorer. Select View->Registry.

2) Under the “Registry on the Target Machine” navigate to the desired location in the registry.

3) Right click on the {adfc4e64-0397-11d1-9f4e-00a0c911004f} key, and select New->DWORD Value.

4) Modify the name of the new entry to match the GUID for your package (it will be in the class GuidList, in the file Guids.cs).

5) Save-all and rebuild the setup project.

That should cause the registry entry to be automatically added to the hive when the package is installed using the MSI produced from Visual Studio.

How to add a setup project

I’m including this just in case the reader doesn’t know how to get a setup project up and running. This article contains a full write-up on how to deploy a project using a setup project:

The above can be cross-referenced with these tutorials for setting up deployment rules:

These are also good references for deploying packages.

Those should be sufficient to get you going.

Alternative method for auto-loading a package

This way (found here) apparently works in the experimental hive, as I could not get the package to auto-load when deploying using the installer. I’m including it here for completeness:

There is an attribute in the Microsoft.VisualStudio.Shell namespace called ProvideAutoLoad. You can decorate your Package derived classes with this attribute. The constructor of ProvideAutoLoad requires a GUID that is the so-called context ID. Visual Studio will load your package automatically when it enters into the specified context. (To get more information about what these contexts are, read the “Visibility contexts” chapter in LearnVSXNow! #13.)

Basically, we need to place a ProvideAutoLoad attribute on the package class that specifies the "NoSolution" visibility context. Factoring in the visibility context information, the necessary code would look something like this:


public sealed class SomePackage : Package

Except that there is one caveat, from the MSDN documentation:

You must pass the GUID value of UICONTEXT_SolutionExists to ProvideAutoLoad instead of its symbolic name. See the enumerated fields of VSConstants for a list of the UI contexts and their GUID values.

So really, the above looks like this:

public sealed class SomePackage : Package


A few hints when you try this feature: do not forget that changing the ProvideAutoLoad attribute requires your application to rebuild. If you find that you have your app rebuilt but it behaves like before (I mean it loads in the same context as it did before even if changing the ProvideAutoLoad context), reset the Visual Studio Experimental hive (with the tool provided in VS SDK).

Monday, November 17, 2008


I'm just throwing these links up for my own reference as much as anything else.

This article seems to argue that Agile is failing in many places due to misapplied Scrum:

But because Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design. Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt. Two or three years later, I get a call--or one of my colleagues does. "Changes take too long and cost too much!" I hear. "Teach us about test-driven development, or pairing, or acceptance testing!" By that time, fixing the real problems requires paying back a lot of technical debt, and could take years.


There are a lot of teams right now failing with Agile. These teams are working in short cycles. The increased planning frequency has given them more control over their work and they're discovering and fixing some problems. They feel good, and they really are seeing more success than they were before.

But they aren't working in shared workspaces or emphasizing high-bandwidth communication. They're don't have on-site customers or work in cross-functional teams. They don't even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don't use good engineering practices.

These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.

Bob Martin, on the other hand, appears to disagree.

Scrum is not the problem. Scrum never was the problem. Scrum never will be the problem. The problem, dear craftsmen, is our own laziness.

It makes no sense to blame Scrum for the fact that we don’t write tests and don’t keep our code clean. We can’t blame scrum for technical debt. Technical debt was around long before there was scrum, and it’ll be around long after. No it’s not scrum that’s to blame. The culprits remain the same as they ever were: us.


It’s also true that scrum leaves a lot to be desired when it comes to engineering practices. But it is neither the purpose of scrum nor of CSMs to make engineers out of us, or to instill the disciplines of craftsmanship within us. That’s our job!

I think Bob's right. You can do lousy design no matter the method. You can write 'unit tests' that test nothing but accessors, or at best contain one hard-coded standard test case for a particular method. You can even write these useless tests before you write your code. You can plan iteratively, but the reality of deadlines produces a pressure to cut corners.

Craftsmanship requires time. If you simply don't have the time, Scrum or not, you're either going to get a lousy and unsatisfying product with lots of features, or a solid yet unsatisfying product with few features.


Sunday, November 9, 2008

Paragraph <p> tags not working in blogger template

For some reason, <p></p> tags weren't working in my blog's style.

I went digging in the template, and located this little gem.

.post-body p {
  line-height: 1.4em;
  /* Fix bug in IE5/Win with italics in posts */
  margin: 0;
  height: 1%;
  overflow: visible;

I changed it to this:

.post-body {
  margin:0 0 .75em;

And voila, paragraph tags actually, well, make a paragraph!

Monday, November 3, 2008

Useful developer tools (some for Visual Studio)

This article discusses ten must-have tools for developers. Many are for .NET and Visual Studio development, and they look pretty cool: 

  • NUnit to write unit tests
  • NDoc to create code documentation
  • NAnt to build your solutions
  • CodeSmith to generate code
  • FxCop to police your code
  • Snippet Compiler to compile small bits of code
  • Two different switcher tools, the ASP.NET Version Switcher and the Visual Studio .NET Project Converter
  • Regulator to build regular expressions
  • .NET Reflector to examine assemblies