Archive: January 2016

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):

https://github.com/alberto-chiesa/SettableJsonProperties

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:

In Which I Pontificate On How a Billion Dollar Company Should Operate

I am anxious today. When we heard that we were going to get a QA director, I suspected that this would not end well for some of us. When I was called in for my initial one on one with the new director, I toyed with idea of just flat out asking if he was here to make some heads roll, but I figured it was pointless to ask this question. Either he was or he was not hired for that purpose and there was little I could say or do that would alter the eventual outcome. Generally, when you work for a department that is considered ‘struggling’ and The People Who Matter Club decides you need a ‘Director’ or a ‘Vice President’ or some other impressive title, you can expect heads to roll. They don’t want to do the dirty work themselves, so they hire someone else to do it for them.

The fallout happened a little at a time, but in hindsight it was obvious where this was going. There is a feeling in the air of waiting for the next shoe to drop. Not all of the fallout was involuntary. Nearly all the original participants in The Chosen Framework, V2, have departed to other teams within the company or for other employers. Those who transferred elsewhere within the company are working on their own automation frameworks, yet The People Who Matter Club still persists in the illusion that The Chosen Framework, V2, will somehow displace all other frameworks, despite our painful lack of resources to do any further development on it. There are days when I regret ever having contributed a single line of code to it because as one of the few developers left standing, I am under tremendous pressure to continue contributing to this project as well as dig our team out from under a mountain of technical debt with respect to the actual automation of regression tests.

For two years, we tried to communicate to The People Who Matter Club that we were not adequately staffed to do our jobs and that lack of communication between development and QA was a serious problem. And for two years, nothing really changed. We struggled to keep up with a never-ending avalanche of new features, the behavior and purpose of which were not well-documented and which were generally introduced to us for testing just before they were to be released. So, predictably, we were always scrambling and of course, always looking as if we couldn’t successfully locate our own asses. Our pleas for additional resources to handle the workload in addition to a sane SDLC process to manage it fell on deaf ears. Then, the new QA director arrives and does the blood-letting that upper management couldn’t bring themselves to do. He says pretty much the same thing that we’ve been saying all along for two years, except that The People Who Matter Club listen to him and now I hear them saying things like, “Hey, we really need a good SDLC process to manage new feature development and we really need to beef up the QA staff levels to handle the workload!”

There has been a lot of heat and fuss around the issue of ‘face time’ in the office. One member of The People Who Matter Club has made this issue a personal crusade and has identified it as a primary reason for the communication problems that have hindered the QA team’s ability to function properly. I could wallpaper the White House if I printed out all IMs and emails I have sent over the last three years that contained questions I needed answers to which went ignored. Silly me, I should have realized that it had _nothing_ to do with a lack of professionalism or consideration that has made it acceptable for people at our company to ignore their colleagues’ emails and IMs! If everyone just limited themselves to one day a week for working from home, the communication would be better! There is a mystical power that is activated when our butts come into contact with our office chair that erases communication problems in the workplace.

The edict came down that we were allowed one day of telecommuting a week. I have an arrangement to work from home 2 days a week for my own personal reasons which so far has not been rescinded, but I am sure it is causing a lot of resentment from others who do not have this arrangement. The fact is… I don’t want to travel into the office 4 days a week. Neither does anyone else. The lack of flexibility with telecommuting is a _huge_ source of complaints at this company. Traveling to and from work is a giant pile of stress and annoyance in this region because There Is. No. Fast. Way. To. Do. It. Traffic is horrific. Public transportation is crowded and slow and increasingly expensive. Imposing the requirement that employees must be in the office means they must devote 2-3 hours of their day traveling. They lose sleep, time with their families and they have to endure stress and frustration to make this trip. All because it supposedly makes communication and collaboration better.

I am not a member of the People Who Matter Club, so my opinion is worth jack, but I going to soapbox it here on this little blog. I’m going to let y’all in on a secret. The benefit of face time in the office for technology workers is overrated. Want to set your company apart and attract a high quality workforce? Let your people telecommute as much as they want. People who are driven to be excellent do not need to be face to face with one another to collaborate or communicate effectively. Good collaboration and communication are personal and individual traits of the employee, not of their physical location. I will point to some of the most successful OSS projects as an example. These projects are developed and managed by people who often never see each other face to face. They often live on different continents. Granted, the class of developer who achieves a role of influence in an popular OSS project is usually a developer of elite caliber, but isn’t that the kind of developer you want? Why pay for all this real estate to house employees who would rather work from home?

So, members of the People Who Matter Club, to close this roundabout post, I want to get back to the issue of ‘communication’. If your rank and file has been screaming for what they need for two years and you hire someone to come in, chop off some heads and then say Exactly. The. Same. Fucking. Thing. only to be treated like a genius for figuring out what the issues are, you might want to take a look at your address. Because, you’ve just bought one of the most expensive houses in Asshole Town.

Share This:

Why Can’t Vacation Last Forever?

I am feeling the post-vacation blues. Not only did I not win the Powerball lottery for the biggest jackpot in American history, I had the unfortunate luck of returning to work in the same week a major release was scheduled to go out. The release was originally scheduled the week before, but it was postponed, leaving me with the unenviable responsibility of being on the conference call for the go-live moment, scheduled conveniently at 11:30 at night. I had volunteered to do the release call while on the vacation, but was told that no one should work on vacation. Frankly, I’d rather do this on vacation because I don’t have to work the next day. I am a cranky jerk when I am sleep-deprived.

The vacation was exciting. We took a long road trip to take the kids to see both sets of grandparents and my sister in Philadelphia. My son keeps asking when we’re going back. I’m sure that being showered with far more presents than any kid actually needs has a lot to do with that. It’s probably also really nice to have a good stretch of time when Mommy isn’t glued to her computer. Guilt? Yeah, I have a lot of that and some to spare. While in TN visiting my parents, we took our kids to a lovely local playground where I managed to get the worst ankle sprain of my life. There is NO logical reason for spraining my ankle where I did. I didn’t step into a hole. The ground was flat and stable. All I did was step off a small platform, a step down of about 8 inches. My ankle just buckled underneath me.

I am proud that I had the fortitude not to scream out the various conjugations of the f-bomb since there was a crowd of small children running around and having a great time. I sat down, blinded by pain, and waited for about two minutes, breathing deeply, until I could calmly call Dan over and tell him I had managed to injure myself for no reason whatsoever. I limped to the car and somehow into my parents house. I was not able to walk on my ankle for the rest of the day. I had to use a pair of my Dad’s old crutches to get around. My sister, the physical therapist, said the healing process is about two to three months for a sprain this bad. I can walk on it now, two weeks later, but it still hurts and feels weak and unstable when it is not wrapped in an Ace bandage and ankle brace. To say the least, my first week back to work was strictly work from home.

Two days after we got home, we went shopping for groceries. On this fateful trip, our son fell out of a shopping cart and busted one of his front baby teeth. It was too damaged to salvage, so it had to be pulled. Yep, we are those parents. The parents who let their kid ride in the back of a shopping cart against all recommendations and warnings posted on the carts themselves as well as the warnings given by the dentists and doctors who have to treat kids who are injured by falling out of these carts every day. Heathcliff will be The Kid Who Is Missing a Tooth for three or four years before his permanent tooth comes in. He will also be The Kid Who Is Never Allowed to Ride In The Back Of A Shopping Cart Ever Again.

In the midst all this holiday excitement and the handling of physical injuries, I did not have much time to work on Brixen. Shortly before we left on the Big Christmas Road Trip, I converted more of the code base over to C# and discovered to my disappointment that the decorator pattern in the Java code base is not possible in C#. Extension methods cannot satisfy the contract of an interface. And since C# does not have the equivalent of default interface methods, I am basically shit out of luck with the decorator pattern in C#. Therefore… this codebase will be a lot more verbose because classes needed to implement multiple interfaces will have to inherit from an implementation of one of them and then provide implementations for the methods of all of the rest of them. So, that kind of sucks.

One of the nice benefits of doing this translation is that it brought to my attention that I had made a bad design choice for the ControllableBean and its associated builder. Reflection is in powerful tool, but it should be used sparingly. Here is the original source code for ControllableBean:

So, this is a total abuse of reflection. The two-arg setters for adding new controls should not take a control name and a class type for the bean. They should take a name for the control and an instance of the bean. This is a much more logical and simpler design and I feel like a dolt for not realizing this from the beginning. Here is the new and improved version of ControllableBean:

This is much better. This interface is easier to implement and easier to understand. These code changes will be uploaded to GitHub soon. Meanwhile, we’ll just keep this little over-complication a secret between ourselves, won’t we?

In other news, it seems that my company is finally going to allow us to use Sauce Labs. I honestly did not think that anything would come of the research into the cost of their services that I was asked to do a couple months ago. However, it seems that we are doing a trial run with them soon and there is a manager assigned to the task of driving it now. I am so excited I can barely contain myself. Having access to some decent infrastructure to run large Selenium suites would be a sea change for my team. It seems that my employer just might have finally taken a first step down the road to building Good Automation.

Share This: