Tag: c#

Preparing for the Coding Interview and Other Tales

Today, I am playing the long game. The one that involves intensive and thorough preparation to get a job where I will have complex and difficult challenges to enjoy. Challenges that involve writing code and not long, involved test cases that take a day to design and debug before I can move on to the next test case that is going to take a day to design, debug and write. I contacted a recruiter who specializes in L33t Coding Jobs and he said I would have to get comfortable writing code on a whiteboard. I am not totally certain of the value of these whiteboard coding exercises over just giving the candidate a computer and pair programming through a bite-size problem with them, but I am getting with the program anyway. If this is the hazing ritual I must endure to obtain the my dream job, then I will endure it.

My chosen guide for preparation is the one that everyone uses — Cracking the Coding Interview. I snagged a 5th edition copy and starting working through the first two chapters. There’s one thing I can say for solving programming puzzles with paper and pencil. It’s slow. Okay, I can say some other things too. It does force you to know by heart the core APIs of your language of choice. I got very familiar with the String and Character methods for handling the entire Unicode character set while solving the problems in the chapter about strings and arrays. Most of the problems are actually pretty decent at working my CS student brain back into shape. Some of the problems are just silly and require you to do something that is dumb and the solution they want you to implement is one that wouldn’t pass code review in a decent company. Like — Delete a node from a list given only access to that node. The answer is “Copy the data from the next node in the list and delete that node.” Of course, this doesn’t work if the node you are give access to is the last node in the list. Normally, I would look at this and think, “Either this linked list API is shit and needs to be re-written because this doesn’t fucking work or the person who wrote this clearly doesn’t have a clue how to use a linked list API.”

Given that there are 150 problems to solve in the book, my interview preparation is going to take a couple months. It is worth the effort to escape the manual testing monster that slowing devouring all my joy. Hopefully, they will replace me with a traditional QA type, so the other SDETs can focus on their automation when I leave. The downside to this is that I haven’t had any spare time to work on Brixen, which is making me have a major sad right now. My next step is to write an EnhancedPageFactory class and some annotation classes so that declaring one of the component wrappers in a page object basically works the same way as declaring a WebElement with a FindBy annotation. Of course, specifying all the data for the component wrapper is a lot more intensive that a simple locator for a WebElement, but I figured that could be handled with a configuration file which is declared by the annotation. The intent is to make all that messiness with having to build the component in your page object go away and become completely invisible.

The other thing that bogged me down with the Brixen work was discovering just how painful and difficult C# is when you are trying to assert equality between collections. By default, C# uses reference equality which is totally ridiculous in my opinion. Who the hell though it made sense to not compare the objects they contain for equality? This really pisses me off. There is an interesting library that does this for C#, but I ran into problems comparing values like 64 bit integers and 32 bit integers. This library doesn’t have some mechanism for upcasting the 32 bit value and then doing the comparison. It just returns false. I realized this when the the library I was using to deserialize data from JSON was taking values like integers and returning then as the type with the largest possible values. So, if I serialize an object with a 32-bit field and then deserialize it, I get a 64 bit value for that field. VERY ANNOYING.

QA Director has become a mite touchy on the subjects of under-staffing and our unstable test environments. Apparently, the California team is even more under-staffed than we are. This is supposed to make us less unhappy that we can’t accomplish our objectives without working nights and weekends, and the logical fallacy of this line of reasoning is totally lost on most people. Be happy about suffering unreasonable expectations because other people are being crushed harder by expectations that are even crazier? Of course, we just made an offer to a manager candidate to replace my boss who was fired two months ago as the sacrificial lamb on the alter of blame for our lack of success instead of hiring more people who would actually do some of the work. Unfortunately, this candidate seems to be of the same delusion that it’s better to have a team of people who are doing both the traditional QA work and the automation. This does not bode well.

If I didn’t already understand how little valued the SQA function is, I’ll share a small anecdote about our upcoming monster release. There was a feature that was supposed to be ready by code freeze. It totally wasn’t ready by then, but we said we’d give it the old college try and test it if they could get it done within a few days. A few days later, the engineering team responsible for writing it said it was all done and ready to test. The person testing this feature started the testing and found that none of the REST end points were reachable. The engineering team is in India, so there follows a back and forth dialog between her and the engineering team with 12 hour delays in between communications. It was working for them, so she must be doing something wrong. As the release date grew closer, the testing could not proceed because the feature just wasn’t accessible to the test team. A meeting was called to make the call about this feature, that went like this:

“So, can we release this feature?” the product managers asked earnestly.
“No, we haven’t tested it,” answered the QA team.
“Great! Let’s release this feature then,” replied the product managers.
“We said no. We weren’t able to test it,” interjected the QA team.
“We all know that when QA says no they mean yes, ” laughed the product managers. “So, we’re good to go.”
“No. We are not good to go. The feature hasn’t been tested at all,” replied the QA team. “Not even one little bit.”
“Why are you being so difficult? I thought you said it worked,” barked the product managers.
“We didn’t say that it worked. The developers said it was working on their machines,” said the QA team who are now texting their favorite recruiters on their phones under the table.
“The customers really want this feature,” whined the product managers.
“We understand that. They probably also want it to work too,” said the QA team.
“Fine. Let’s talk about this again in a few days. Maybe the customers can test it for us.”

This happens all the time.

Share This:

Optional Types and JSON Deserialization for C# for Brixen

Every small victory shall be rewarded with the next battle. Now that I have completed the task of doing the C# implementations of all the state beans in Brixen, I am planning the translations of the configuration beans. Preliminary research indicates that the closest equivalent to Java’s Optional type is the Nullable struct. And there is a tool for marshalling JSON data into object instances: Json.NET. Once I had established those facts, I had to tackle the same issue I had when approaching this problem in Java, which is: How do I distinguish between a missing key an an explicitly null value? And I determined that there is no built in way to do this and will require work on my part to make it happen. It also led to a funny Stack Overflow post where someone posted their implementation with the caveat:

I uploaded the implementation into a repository on Github, for everyone to use (no warranty, use at your own risk, etc… I’m in hospital with 6 broken ribs and under painkillers: if something doesn’t work it’s YOUR fault):


So, I will most likely be following the guidance of someone who was under the influence of strong painkillers. I expect this will be an epic journey involving a lot more coding than was necessary to pull off the configuration beans in Java.

Share This:

In Which I Bitch and Moan a Bit More

First, I would like to bitch about C#. I finally translated the whole state Brixen Java bean package into C# and both the C# and Java versions are fully unit-tested. Yay! Second, C# needs something like Lombok _ASAP_. I did not fully understand The Giant Teh Suck So Much that it is to write all this freaking boilerplate for ToString(), Equals() and GetHashCode() over and over again until I enjoyed not doing it for Java classes for the last year. It’s glorious to open up a class file and Not. See. That. Shit. I am bummed there is no way to do the decorator pattern in C# as I have done it in Java. That little beauty of a design pattern _really_ cuts down on boilerplate. And Equals() for collections such as Dictionary, the equivalent of Map for Java, totally blows because it does reference equality, not ‘contains the same shit’ equality like Java Map implementations do. Seriously… what the fuck? Who thought that was a good idea? This took far far longer than I thought it would. I thought I would be done with the C# translation before Christmas and that I would be blazing through the Python implementation by now. Writing unit tests is tedious and time-consuming, but having caught some bugs with them, I am happy I have committed to doing them in tandem with the C# translation. But enough about that. Brixen marches onward and the source is available here. Looks like someone forked my repo a while back. I am flattered.

Today, I am _not_ gruntled. Far from it. You probably would have guessed that from the mere fact that there is a new post today. I had my annual performance review and the result was good, but not spectacular. I feel satisfied with this outcome and it is what I expected. This was a rocky year for me, and I did a few things which embarrassed the QA director. I publicly contradicted his goals and strategy on a fairly high-level initiative he was pushing, and I chewed out the Principal SDET over email for checking crappy page objects into the core of the automation framework without so much as a word with me over it. So, the chickens are coming home to roost for me. I have always had a mouth that got me into trouble before my rational brain could stop me. I have a habit of just expressing things in a way that others find too blunt and not diplomatic enough. I also have a temper.

Today was one of the days in which my rational brain was too slow out of the gate to catch up with my mouth. A junior developer is taking on the task of translating the regression suite I wrote to run against the new, totally rebuilt front end. I expected this task to be difficult for her. The regressions suite tests the application that has the biggest, most complicated UI in the entire customer portal. That shit is hard and complicated and the page object modeling is a non-trivial challenge. Today, she called a code review that included me, the Principal SDET and two other team members. In the midst of the code review, the question came up about labels I have attached to the test cases in JIRA which are reproduced on the test method as group names. I have a longer term plan for using those labels and the group name mappings as a way to dynamically select methods for specific functionality on the fly so that a developer can trigger a build that selects tests that cover the functionality they touched in their commit. Principal SDET claimed I had agreed to take the labels off the Jira test cases and the test methods. Problem is, I have near perfect memory for conversations going back months, and I knew that I had not agreed to do that. In fact, she and the QA director had backed down from it when it last came up. I disagreed with this assertion and before I knew it we were shouting at each other over the phone and she was refusing to explain why the presence of these labels was harmful to anyone.

After a chat with the QA director, I will be doing a presentation next week to explain why I did this and where it is going and then put it forth to the team to decide to chuck this or not. If they decide to chuck it, then I will copy all my work elsewhere and continue implementing a parallel test suite that uses this plumbing and present it to the development team when it is ready because this whole thing was meant to help them anyway. I have no idea where this came from and it is not the first time an issue which had been settled has been raised again from the dead where I am told I have to change how I did something without getting a clear explanation for why I need to. I am getting… weary of this. Principal SDET has a habit of honing in on trivial, non-architectural things which harm no one and making a giant fucking deal out of them. Test data storage formats are a giant bugaboo and apparently everything must and should be stored in a Java Properties file even though Java Properties files are flat, key/value pairs and there is no tooling I know of or that she can point me to which will allow me to suck in a Java Properties file containing serialized data that represents collections of objects and their state and instantiate collections of POJOs with it. At one point, the directory structure of the framework was a giant burning issue. If someone checked something into the wrong directory or tried to use Maven modules to manage multiple, related projects, they were not following ‘architectural’ guidelines. I have no idea what important architectural implications any of this has since they have NO EFFECT on how any particular subsystem interfaces with any other subsystem.

The code review barely touched on anything related to actual form and function of code. I don’t know if it is worth it in the long haul to stick around in this role. I like the challenge of the stuff I work on, but this perennial micromanagement and drama is getting really old.

Share This:

Fumbling Around Like a Total N00b: Translating Brixen from Java to C#

I spent a week scratching my head over failed unit tests that were ultimately the result of jackass n00b mistakes, and sadly, they were not C# n00b mistakes, but Coding 101 n00b mistakes like not checking for null and failing to actually set the value of a property after validating the parameter for its setter method. Oh, and leaving off the parentheses for a method call. Thankfully, I didn’t turn to Stack Overflow for help. My reputation would have taken a severe nosedive for requesting help with such embarrassingly basic bugs. And this, my friends, is why you should write unit tests. It saves you from checking dumbass Coding 101 mistakes like this into source control where they can be found by your co-workers who might be tempted to slowly freeze you out from the important and rewarding work because they just can’t trust you to write a decent for-loop without a user’s manual at your side.

I still haven’t figured out how to write an integrated build script for Brixen that would compile, test and deploy both brixen-java and brixen-dotnet. I did however, take the time to learn some basic Nunit framework usage so that I could actually write some unit tests. I also tried to integrate Nlog logging into the unit tests, but for some reason, the logging statements don’t get output to the console in Xamarin Studio, so I took it out. I think I need to try this on a Windows system with Visual Studio.

When I started coding, I realized I had no idea how a standard .NET project should be organized. I went in search of a guide and found that finding such a thing was not all that easy. It’s as if there is this pervasive assumption in the .NET coding community that you should just know how to structure a .NET project by osmosis. With Maven, there is a well-documented project structure and there’s generally no question where something should live. Java enforces a directory structure convention for packages which does not exist in the C# world. YouTube came to my rescue in the form of a short, awesome video tutorial where the creator of the video explained that these things are in fact often hard to figure out because they are not explicitly documented by Microsoft.

After basically learning the basics of a totally different tool chain, I finally got something that I could check into the Brixen GitHub repo that I was not ashamed to call my own. So far, I’ve only translated a handful of the state beans into C#, but things should move faster now that I have surmounted some of the learning curve. The code is definitely going to be more verbose than the Java version due to the lack of a tool like Lombok. I have to write implementations of ToString(), GetHashChode() and Equals(Some Object) which is tedious. In Java, I can just throw a couple annotations on a class and these methods are auto-generated at compile time by Lombok. I’ve updated the corresponding Java classes too. In the source code I presented at the Selenium conference, I did not do any parameter validation for the setter methods because I wanted to cut down on the sheer volume of code I had to present. I am now adding back in the parameter validation that I cut out because it’s just a good idea to validate parameters. So, the Java code is more verbose than the code from my presentation.

The Decorator translation is a little harder to pull off in C# because I have to use extension methods to produce something like the default method implementations that Java 8 allows, but at least, thankfully, it is possible to do. I treated myself to the pleasure of reading explanations of why Java 8 was just totally wrong for allowing this atrocity into the language because it violates the very definition of an interface. This may be true, but default interface methods are just astoundingly convenient in ways that justifies the atrocity in my opinion.

Share This:

Learning a Foreign Language: Translating Brixen From Java to C#

I started translating the existing codebase for Brixen from Java into C#. I mistakenly thought this would be a quick and easy task because the syntax of C# appeared to be so similar to Java. Syntax Schmintax. I didn’t realize how fundamentally Java had arranged my thinking around How Development Works. My first jolt was discovering how bonkers I was for thinking that it would be a breeze to do this. I was thinking that all I would need to do is install a plugin for IntelliJ and I would be golden. If I couldn’t do that, surely I could just use Eclipse. Fast forward two weeks, skip over a lot of cursing and forehead slapping, and I am using Xamarin Studio. It took a while, but I came around to accepting that you just don’t mix C# and Java in the same IDE. It’s. Just. Not. Done. I also eventually accepted that C# isn’t platform independent, and developing in C# on a Mac is kind of whack.

My second more unpleasant jolt was that Maven doesn’t support C#. This one was a lot harder to accept. I thought it would just be a matter of adding some new dependencies in the POM for Brixen, adding a build plugin or two and I’d be good to go. I would have brixen-java and brixen-dotnet playing all nicely together and all I needed to do is type ‘mvn install’ and shit would just work. It was really hard, but I finally accepted that this isn’t how it’s going to be. I still have no idea how to do the build and deploy thing for the C# packages, but I decided to defer that task while I try to learn the C# language.

There’s no Lombok for C#, but there are these things called properties which sort of do the same thing. The naming conventions in C# are whack. Seriously?! PASCAL IS SO OVER! Interfaces can’t have fields?! The languages are similar enough on the surface that it’s not too difficult to translate from one to the other, but they are different enough that I am regularly irritated and pissed off in some fashion. It’s like a rash that isn’t bad enough to make you go see a doctor, but still annoying enough that you really really want a steroid shot JUST TO MAKE IT STOP ITCHING. I just have to say to all you people who love C# — WHY? Why do you love it?

Share This: