Yearly Archives: 2015

Simple vs “Simple”

Uncategorized, ,

F# has two key features that makes the code very compact. Significant whitespace and forced compilation order.

Significant whitespace removes the need for curly braces or the use of keywords such as begin/end. Forced compile order means your dependencies have to be declared in code files above yours in the project declaration. This gives your F# projects a natural reading order and makes projects follow a natural order that transcends individual style.

Now there is a user voice suggestion that the enforced compile order be removed.

I think this is a good idea. I am against project files. As soon as you have three or more developers working in the same group of files, any one file used to maintain state is bound to become a source of merge conflicts and strife. Just look at C#.

I am sure your IDE could evaluate the dependency order of your files and present them in that order for you, heck one could probably make a CLI tool to show that same information if the navigational benefits of the current order is what is holding you back. Let us break out of IDE-centric languages and allow the programs to be defined in code rather than config.

Rebootcamp

.NET, Architecture,
I have been saying a bunch of things, repeating what others say, mostly, but never actually internalised what they really meant. After a week with Fred George and Tom Scott I have seen the light in some way. I have seen proof of the efficacy of pair programming, I have seen the value of fast red-green-refactor cycles and most importantly I have learnt just how much I don’t know.

This was an Object Bootcamp developed by Fred George and Deliberate and basically consisted of problem solving in pairs going over various patterns and OO design in general, pointing out various code smells to look out for and how to refactor your way out of trouble. The course packed in as much as the team could take over the course of the week and is highly recommended. Our finest OO developers in the team still learned new things over the week and the rest of us learned even more.

Where to go from here? I use this blog as a way to write down things I learn so I can reference it later. My fanbase tends to stick to my posts about NHibernate and ASP.NET MVC 3 or something from several years ago, so I need not worry about making things fresh and interesting for the readership. The general recommended reading list that came off of this week reads as follows:

So, GoF and Refactoring – no shockers, eh? We have them in our library and I’ve even read them, even though I first read some other derivative book on design patterns back in the day, but obviously there are things that didn’t quite take the first time. I guess I was too young. Things make so much more sense now when you have a catalogue of past mistakes to cross-reference against various patterns.

The thing is, what I hadn’t internalised properly is how evil getters and setters are. I had some separation of concerns in terms of separating database classes from model classes, but still the classes didn’t instantiate good objects, they were basically just bags of data, and mediator classes had business logic, messing with other classes data instead of proper objects churning cleanly.

Encapsulating information in the system is crucial. It is hard to do correctly, but by timeboxing the time from red to green you force yourself to build the next simplest clean thing before you continue. There is no time for gold plating, and boy you veer off and try something clever only to realise that you needed to stop and go back. Small changes. I have written this so many times before, but if you do it properly it really works.  I have seen JB Rainsberger and Greg Young talk about this, and I have nodded and said sure. Testify! “That would be nice to get to do in practice” was my thinking. And then I added getters and setters to my classes. Or at least made them anemic by having a constructor with parameters and then getters, used by demigod classes. The time to make a change is yesterday, not tomorrow.

So, yes. Analysis Patterns is a hard read, said Fred. Well, then. It seems extremely interesting. I think Refactoring to Patterns will be the very next thing I read, but then I will need to take a stab at it.

I need to learn where patterns could get rid of code smells, increase encapsulation and reduce complexity.

There is a handy catalogue of refactorings that I already have a shortcut to in the chrome toolbar. It gets a lot more clicks now, but in general I will not make any grand statements now but rather come back with a post showing results.

Powershell woes

Uncategorized
What is the point of powershell?
Trying to orchestrate and automate distributed tests with powershell leads to things such as using remote powershell or psexec to start tests on VMs and to use PSDrives to set up tests and collect logs.
So then you would like some calls to be reliable. Starting WinRM on a remote box, or setting up a PSDrive to get fresh executables to VMs or collecting logs neesd to be reliable.
With a 10% successrate out-of-the-box you wonder how people ever use this stuff, and the truth is of course people don’t, they write reliability layers around it with retries and exception handlers, just for the Happy-path nothing-important-has-failed scenario
Had MS spent the extra five minutes to make the built-in code be less unreliable and weak and perhaps to only return a failure once every means to recover the situation had been exhausted would have spared every single powershell user the work to write their own reliability layer just to get the basics working.
Case in point:  New-PSSession. There is no way in the known universe that should be allowed to fail. OK, if there are HTTPS certificat problems or network connectivity problems, say so, but other than that I deserve an apology. Eloquent and part of the return object.  Problem is 90% of the time New-PSSession will fail, for no reason. No reason whatsover.
I mean I know the test triangle and all that, but for that tip of the triangle I don’t need any help from MS to make the system test EVEN MORE EXPENSIVE to make and maintain.

UTF-8

Evil, General, Win32

Having grown up in a society evolved beyond the confines of 7-bit ASCII and lived through the nightmare of codepages as well as cursed the illiterate that have so little to say they can manage with 26 letters in their alphabet, I was pleased when I read Joel Spolsky’s tutorial on Unicode. It was a relief – finally somebody understood.

Years passed and I thought I knew now how to do things right. And then I had to do Windows C in anger and was lost in the jungle of wchar_t and TCHAR and didn’t know where to turn.

Finally I found this resource here:

http://utf8everywhere.org/

And the strategies outlined to deal with UTF-8 in Windows are clear:

  • Define UNICODE and _UNICODE
  • Don’t use wchar_t or TCHAR or any of the associated macros. Always assume std::string and char * are UTF-8. Call Wide windows APIs and use boost nowide or similar to widen the characters going in and narrowing them coming out.
  • Never produce any text that isn’t UTF-8.

Do note however that the observations that Windows would not support true UTF-16 are incorrect as this was fixed before Windows 7.

Powershell

Uncategorized

I am extending some tests we are running in powershell. It is used to validate that the chef configs we are setting up so that all moving parts are running.

One thing I tried to google that wasn’t  perfectly clear to a n00b like me was how to use static objects in powershell, specifically take byte array and interpret it as a UTF8 string.

Apparently this is how you do it: 

$enc = [System.Text.Encoding]::UTF8
$c = $enc.GetString($result.Content)

Where the $result came out of a WebRequest. This means I can test that $c contains an expected value and fail the script, and thus – the build, if the result is unexpected.