Bloody space in a form input name

Suppose that you have to HTTP-post a form with some pre-computed hash field to a service. You prepare the form as HTML or as an HTTP client call, with a hidden input field or a request body parameter that is (apparently) named hash and submit it.

But you receive an error from the service, like this:

The computed hash is different than the hash in your request.

You struggle to see what’s the difference, thinking that maybe your hash generation algorithm was incorrect or incomplete and sometimes you might work for a few hours on this to only see eventually that… there was an inadvertently entered space in the name of the input field:

<input type='hidden' name='hash ' value='{computedHashValueHere}'/>

In this case the hash<space> field is correctly sent with the form, but the service might not match it to the expected hash field, and also it might not inform you that the expected hash hasn’t been received at all, especially if it’s implementation is poor (like that of, for example).

And you won’t be able to easily spot the issue with a network sniffer either (e.g. Fiddler), since the space will probably be there in the view just as an (obviously) invisible char!

Lesson learned: be very, very careful and cautious when you define your request in these situations. Check for supplemental or missing spaces, lowercase vs. camelCase vs. PascalCase vs. UPPERCASE vs. ANYOtherCase, and also check that the form root element is defined correctly.

For the latter case (regarding the root form element definition), note that the example form below will only send one field – the second – feel free to try it yourself and check the form in the browser’s DOM (using developer tools) to detect the issue:

<form id='myForm' method='post' action='">
  <input type='hidden' name='x' value='{x}'/>
  <input type='hidden' name='y' value='{y}'/>
  <input type='submit' value='submit'/>

Or, if you don’t have the time to do it, just check this screenshot – it will help you easily identify the incorrect ending character for the action attribute of the form definition (double quote instead of single quote):


Posted in HTML5, WebAPI | Tagged , , , , , , | Leave a comment

Auto-disposing? Empty using syntax?

What do you think? Should this code auto-dispose the X object instance created but not used? If you test it, you’ll see it does not:

public class X : IDisposable { … }
static void Main(string[] args)
    Get(); // Doesn't dispose result.

static X Get()
    Console.WriteLine("Getting X...");
    return new X();

As you can see, the Get() call in Main will cause the side effect of constructing a new X object, which is disposable. But Main doesn’t actually use that object – it’s interested just in other side effects caused by Get method to occur, such as to have the Getting X… string written to the output stream.

The compiler could easily infer that the caller doesn’t need the object and it might just inject a Dispose() call on the result of the call that is not put into a var. This would avoid the need of this empty using statement to do the disposal in an explicit way, which seems so awkward, and brings further questions – such as whether to do it or not – especially as X can be Task<T> and in that case it’s commonly used with .NET 4.5’s asynchronous code:

using(Get()) { } // Disposes result.

A possible reason against auto-disposing, though, might be that without the explicit using, maybe the caller is also interested in having the X object healthy (i.e. not disposed) in memory for the next undefined period of time – maybe X just adds itself as a listener to some static object events, for example, and in this case, disposing it blindly might cause unexpected results.

However, I personally think that at least the language should permit this syntax sugaring – and I wonder why nobody thought of it already, as C# reached version 7 this year!

using(Get()); // Doesn't compile!

Ah, I see the problem now! Actually the syntax should better be:

!using(Get()); // But still doesn't compile, of course! :-)
Posted in C# | Tagged , , , | Leave a comment

Using CSS attribute selector to simulate a CSS style selector

Although it might be considered strange by some, sometimes we just want to set up CSS styles on elements selected based on other style values, that are set in other ways, such as inline styles placed by internal JavaScript components that our app uses.

Here is a real-life example. Let’s assume that inside a grid we want input elements of all cells to have a specific height:

.cell input {
    height: 24px;

However, inside some grid columns we use a multi-selector combo box component, displaying multiple items with checkboxes in a pop-up whenever the user clicks the drop down button, allowing him or her to change selections to apply to the cell value. And because the checkboxes from the fixed position and z-index-enabled pop-up are internally considered logical parts of the grid cells, the style for input elements declared above applies to them too, but we clearly don’t want that!

To resolve the problem, we can try using an attribute selector and restore the height to auto for input elements inside the pop-up using the style attribute itself:

.cell [style*="z-index:"] input {
    height: auto;

Strange but this works if the popup is defined with an inline style containing a z-index setting. You can also add the exact value of z-index but then it is important to check if there is a space or not between the column character and the number and copy it properly, because the selector will check the string in a strict fashion. (Too bad that – at least so far – there is no wildcard character that we could use inside the checked value.)

Posted in JavaScript | Tagged , , , | Leave a comment

Developer focus selector

From low level to high level programming, software developers need to select a good technological area to focus on, since nobody would ever know well everything:


Of course, the diagram above is not exhaustive, and it can be seen as just a sample technology sheet. But it allows us to observe some things and draw some (hopefully good) advice regarding the selection of the development focus point that one should embrace, especially if it’s a newcomer to the IT world:

  • Freedom vs. productivity:
    • If you select lower level technologies, you will have more freedom in development, but it will be more difficult to get your app developed and maintained.
    • If you select higher level technologies, you will have to use the framework within its use case boundaries, but it will be easier to get the app released, and maintenance will be easier.
  • Cross-platform limitations vs. multi-platform difficulty:
    • Sometimes a higher level framework will make more lower level technologies compatible at a logical point of view, allowing you to learn less and develop faster, and with more ease; e.g. Xamarin uses only C# and allows you to develop apps for UWP, Android, and iOS without having to learn Swift and Kotlin;
    • However, cross-platform frameworks typically come with many limitations that you won’t have otherwise, especially when you reach to corner cases or want specific features that lower level technologies offer; but if you want to learn multiple platform technologies separately and avoid such limitations, prepare for other type of difficulties: less time left for actual development due to the always learning need, and sequential release chains or longer time between different platform releases.
  • Extended focus – whichever primary focus point you choose, however, you should learn a bit both at lower and at higher levels (whenever and as much as possible):
    • Learning lower level technologies will allow you to understand better how your (otherwise black box) framework works, especially regarding performance, but also addressing user experience or other common app development concerns.
    • Learning higher level technologies will allow you to prepare your code so that it’s usable also from those upper frameworks with more ease, just in case that would be eventually needed, such as to expose components from your area to other projects or even to the general public in the development niche.
Posted in Development | Tagged , , , | 1 Comment

Why interfaces?

We should almost always extract interfaces from your service classes because:

  • We should use dependency injection to load and compose implementations: to avoid the need of manually constructing chains of dependent objects and/or to be able to release implementation changes without rebuilding the entire solution, if dependencies are dynamically loaded.
  • We should isolate and test client callers and for this purpose we need mocking; mocking is a lot easier if the call is performed through an interface.
  • Rarely for polymorphism (although this might be their most obvious use): only if really, really needed – I’d say we should always consider composition first; thst would probably save us from much unforeseen trouble!
Posted in Development | Tagged , , , | Leave a comment

Can we skip unit tests for infrastructural code?

Almost always we end up with infrastructural code in our projects. That is extension code on top of the framework that we’re using internally, added so that the main functional code of the app is cleaner, clearer, shorter, and also more testable – since it it separated from its infrastructural dependencies through custom “mockable” interfaces that we expose and that might otherwise be missing.

(For example, many times we design and use a generic – although probably app specific – data access layer that internally accesses a database and provides data and saves back data changes to and from the app services.)

The infrastructural code tends to become complex, and will eventually also contain logic, so we might consider it a good candidate for unit testing, isn’t it? But then one would immediately think again: won’t such tests be very difficult to write? Does it really worth to write them?

To answer, let’s first think a bit about the reasons of unit testing in the first place:

  • We want to find issues early. Yes, usually writing unit tests help us detect issues fast, immediately after or even before the code of the tested unit is complete, i.e. before running it together with other parts of the system.
    • But in practice if the unit test is difficult to write – as it happens many times with infrastructural code – it’s very probable that it would actually take more time to get to the problem through unit testing, than compared to simply running integration tests – using the first functional unit and the tested infrastructural one – or even to just running an early system test on the development machine with the debugger!
  • We want to be prepared for maintenance. Yes, proper unit testing ensures that other team members (and ourselves in the future) don’t break existing functionality without knowing – when changes are requested by customers or when we decide to refactor code for any other reason.
    • For infrastructural code this is indeed important, but in my opinion the difficulty of writing unit tests isn’t beaten by this reason alone! Instead, I have seen that:
      • infrastructural code tends to change very rarely,
      • and even when it does it is immediately retested through integration tests from functional areas and through system tests that do need the infrastructure in place and working well anyway.
  • We document our code. Yes, if we write unit tests with a good naming technique, their names can turn into documentation!
    • But for infrastructure we should also write and maintain some better documentation anyway!

However, because I’m sure I won’t convince anyone that one may safely add infrastructural code into his or her app without any measures against regression on forseen maintenance in that area, I want to propose an alternative:

We can somehow lock the infrastructural code so that whenever a change is really needed there, it is done with extra care and closer code review.

(Actually, as an anti-regression technique, unit testing is also a mechanism to lock code, as if one needs to change tested code, he or she would be forced to ensure all tests still pass or are updated themselves to run against the new logic – fully assumed and signed upon by changing the tests.)

Currently development environments don’t seem to offer a lock code mechanism as it would be needed by my proposal, but I think it won’t be very difficult to implement one as an IDE add-on.

For example, I am thinking of a [LockCode(Hash=”…”)] attribute added on an infrastructural C# service class by simply right clicking the code in that class and selecting a Lock code command in the context menu. The argument value would be computed automatically by loading the class code and computing a hash on it.

  • Now if somebody would change that class, the hash won’t be correct anymore, and in this case the environment could trigger a high priority warning. Of course, this warning would appear also if the code refactoring is 100% OK and the changed class would run exactly as before, i.e. if all unit tests would have still worked in case they existed. But from my point of view this is something that we can live with instead of the hassle of having to implement and maintain unit tests there!
  • Furthermore, we can think of new project rules, such as requiring double code reviews for code changes that include adding or updating hash values, to increase maintenance safety.
  • With such an approach we will gain a lot of time from skipping the task of writing complex and difficult unit tests on that rarely changing code, process that might otherwise require adapters and wrappers over the internal core framework objects to actually obtain testability! And we will release faster than our competition!

What do you think? Would such a locking code mechanism be useful in your case?

Posted in Architecture | Tagged , | Leave a comment

Platform selection

Want to develop apps? You need to decide whether you want to do it for a single platform or more, and in the latter case whether or not to use a cross-platform framework. The table below may help, but you’ll need to weight the advantages and disadvantages yourself.

(Note that if you want to write components for multiple development platforms, you need to assume that cross-platform frameworks are different target platforms for your components as well!)

Single platform Cross-platform (single framework), native output Cross-platform (single framework), interpreted output Multiple platforms
E.g. One of:

  • WPF (C#)
  • UWP (C#)
  • iOS (Swift)
  • macOS (Swift)
  • Android (Kotlin)
  • Linux (C++)
  • Web (TypeScript)
  • Unity 3D (C#)
  • etc.
One framework:

  • Xamarin: UWP, iOS, macOS, Android (C#)
  • Unity 3D: UWP-HoloLens, desktop, Web (C#)
  • etc.
One framework:

  • Cordova: UWP, iOS, Android, Web (TypeScript)
  • Electron: Windows, macOS, Linux, Web (TypeScript)
  • etc.
More/all of:

  • WPF (C#)
  • UWP (C#)
  • iOS (Swift)
  • macOS (Swift)
  • Android (Kotlin)
  • Linux (C++)
  • Web (TypeScript)
  • Unity 3D (C#)
  • etc.
Learning Easy, short Medium Medium Easy, long
Native apps (good performance) Yes Yes No Yes
Expected issues Few, easy to fix Many, difficult to fix Many, difficult to fix Many, easy to fix
Maintenance Easy Medium Medium Easy, long
Market size Small Large Large Large/Largest
Posted in Development | Tagged , , , , , | 1 Comment