Misc

Don’t shortchange architecture.

Can I say, I’m actually a little disappointed in EntityFramework right now. We were moving to more of a model based solution with the second version of our software, but found these pitfalls:

  1. In all but the simplest Admin forms stored procedures will be necessary. For example, you will want to update against a table – but run checks against a balance, or update a ParentID, or modify related information – you’ll have to spill across multiple entities. The simplest way I know of doing this without a lot of wasted code is db-side sprocs.
  2. EF works TERRIFIC when you’re binding directly to a table. But as soon as you have to use sprocs there’s a TON of manual coding and clicks that has to happen. This means the same or more amount of work than in old-school DAL layers.

For example, look at this EF sproc mapping:

Say it with me – Eeeeessshhhhh. Having done a few dozen of these mappings so far I can say it’s a painful process and as fraught with peril as any DAL layer. And, since it’s graphically based and not a class, I frankly don’t trust it as much when it comes to making changes. EF does a good job of prepopulating many of these, but not always – especially if the table name and the field name are the same, or if the casing is slightly off (Id versus ID for example). I may end up sighing, throwing up my hands, and rolling back to a SqlDataSource instead.

Long story short – I would love to blame our ever-increasing list of functionality but specs are specs, and I don’t think things like soft-delete or cascading changes are unique to this application/working environment. And, I’m looking back on the road we chose not to take – BOWA (Breeze-OData-WebAPI-AngularJS) and wishing we had spent a few more weeks on architecture and a firm set of guidelines/standards. It would have paid off handsomely when it came to maintenance and durability for this app.

Science cannot move forward without heaps!

So today I was having an issue where the site would build perfectly locally, but would burp up garbage when I published it out to DEV. So, after messing around with the source code a little, I started back at the beginning, with a raw HTML page, then built a master page, and voila – the issue was in something I’d missed in migrating the CSS code over from an older site. Now I could build my monument to CSS3/HTML5 while ignoring the piles of dead code littered along the path behind. Reminds me of that classic Futurama quote:

Professor Farnsworth: “This time I’m sure I fixed the mind-switcher.”

Amy: Good. I’m sick of cleaning up those heaps of dead rhesus monkeys!”

Professor Farnsworth: “Science cannot move forward without heaps!”

 

An interesting article on the ultimate dead end of ‘truthiness’ here – Language and the Cheshire Grin of Donald Rumsfeld: “…He was trying to articulate a philosophy, and in articulating the philosophy he was basically saying things that he believed but which made no sense. I think that’s probably the best way to describe it. He knew these expressions. He wrote this to the president of the United States: “The absence of evidence isn’t the evidence of absence.” … Then all of a sudden the ballistic missile commission picks it up, and Rumsfeld runs with it, and it’s trucked out during the run-up to the Iraq war.  UN weapons inspector goes to Iraq and can’t find any evidence of a WMD—that’s not absence of evidence, that’s direct evidence that the suspected WMDs are simply not there. The way I describe it is that it’s like someone tells you there’s an elephant in the room. You open the door and you look in the room, you open the closets, you look under the bed, you go through the bureau drawers, and you don’t find an elephant. Is that absence of evidence or evidence of absence? I would submit it’s the latter. But this gobbledygook use of nomenclature and terminology just creates endless confusion, vagueness, ambiguity—and I would submit that they kept doing this with respect to everything.” 

Blogging notes and tools… Viva Live Writer and PreCode!

Last night my wife and I – on one of those once-in-a-blue-moon date nights – went to a great concert at the Mississippi Studios in North Portland. The opening acts were TERRIBLE – especially the ‘performance artist’, which was a complete trainwreck. We’re talking screeches, weird jerking kind of dances, losing her notes and shuffling through papers on the floor, and these long awkward pauses. But, Catherine Feeny was TERRIFIC. I was so impressed that she was able to do so much with a two-person group. It was a GREAT show! (The fact that the tickets were under $8 made it all the sweeter.)

I’ve been a lazy blogger for a long time – meaning I just copy-and-paste my images into Microsoft Word, and publish. No muss, no fuss, and the tool doesn’t get in the way. The issue is, my code snippets don’t surface properly. Images can’t be googled and are evil for code; the hoster I’m using (sadly) doesn’t like a <scripts> tag or anything beyond plain vanilla HTML. So, what to do?

I set up Live Writer recently and have been experimenting with it, in combination with the PreCode tool at this location. It’s relatively easy to set up – once you’re in you can just click on the “PreCode” snippet on the insert toolbar:

image

This gives me a nice snippet as below.

 

 

        public void Configuration(IAppBuilder app)
        {
            app.MapSignalR();
            //ConfigureAuth(app);
        }

 

Really all it does is insert a < pre > tag around your HTML like this:

image

 

Simple, and beautiful. Just like Catherine’s music!

Scott H did a great post on the subject, if you want to get a leg up on the other options available to you…

Salary Negotiation for Sissies.

First off, may I say, I really SUCK something awful at negotiating salary. And why wouldn’t I? I do it maybe once a year, if that; I’m negotiating directly for myself (no middleman), and it’s outside my core skill as an engineer. I want to move past this as fast as possible and get back to doing what I love: everything BUT talking about money. Well, guess what? That’s the story of every other programmer I’ve ever met.

I’ll do you a solid and not drone on endlessly what you can read in more detail (and much better written) elsewhere. But, it does come down to these points:

  • Never give a number.
  • Salary negotiation is the most important financial decision you make. More even than owning a home.
  • Your actual (fully loaded) cost to an employer is several times your base salary. They will not get a bonus by nickel and diming you, and they will not be offended if you ask. You will not be blackballed. $5,000 is, in the scheme of things, chump change.
  • They’ve sunk thousands invested in just talking with you, so – assuming you have agreement-in-principle after several rounds of interviews – they want you. Negotiating will never make worthwhile offers worse.
  • Once again, never be the first to give a number.
  • Use words like “We” and “You” (which is better, since people care a lot more about their problem than yours.)

Ahead of time you should know the following:

  • What the marketplace will support.
  • What you are worth, what value you provide – with specific examples.
  • Know your three numbers – the money you want, a good “settle” number, and the drop dead bottom line. NEVER tell them that third number!

Do NOT say – “What’s the salary range?” You should already know this from your market research. Dice and LinkedIn exist, use them! In your tone, don’t be adversarial – and give longer answers than in interviews. Iterate that you’re excited about the job. The tone is, I want to be here, I’m going to add a tremendous amount of value, here’s what I’m worth – let’s find a fair # that works for both of us.

Talking Points

So here’s some scripts to talk from:

“What’s your current salary?”

  • Do NOT say: A specific number. You can’t lie here. But you are backed into a corner… and this isn’t the time to So you evade:
  • I’m willing to entertain any reasonable offer.
  • I’m confident I’m within your range.

“I really need a number to move the process forward.”

  • Do NOT say: First and foremost, NEVER give a number. They’re trying to get you to compromise your negotiating position.
  • Say: “I’m more concerned about discovering whether we’re a mutual fit. If we’re a great fit, then I can be flexible on the numbers with you and you can be flexible with me. If we’re not a great fit, then numbers are ultimately irrelevant, because your companies only hires A players and I only work at roles where I would be an A player.”
  • Honorable mention: “It’s so important to me that this is a good mutual fit. Let’s talk about why I’m a great fit for this position; I know you’re concerned about ____. In addition to my previous successes, I have some great ideas on what I’d do on this… Would you like me to drill into those or is there another job area you’re more concerned about.”
  • Well, you know, I would hate to have to walk away from the negotiation over this. Working with your company looked like it would have been such a wonderful opportunity. The market is tight right now. Hmm. Well, salary is one part of the total compensation package. In terms of total compensation, we’re probably looking at something like $200K, correct? (30-50% + FT salary)
    • OTHER AREAS: Training. Vacation days. Project assignments. Travel.
  • “Hmmm. This is an important decision where we both have to walk away happy. That means me taking a specific number to my wife for consideration.

“We were thinking about $60,000 and maybe throwing in a can of pork and beans.”

  • “60,000 is interesting but not quite where we need to be to get this done. Do you have any flexibility on that number? … That isn’t quite what I had in mind, but the right package offer could make that attractive. How much vacation comes with the package?… If you could do X days a year (or a bonus of $___, etc), I could compromise on $*****.”
  • “First off, I just want to say, I’m very excited about this opportunity. I really want to work for XCORP. The experience I bring to the table in previous roles directly translates to this and I believe warrants a much higher salary. In terms of my own research on the marketplace, the range is more like $XXXX to XXXX. Given my experience and my ability to deliver value, I believe I deserve to be at the higher end of the scale.
  • At the end of the day, I would look at this as an investment. At the end of the day, I think I’ll be able to deliver more than that $XXX difference.

OK, I talked with my manager, and he’s offering $67,000. Plus two cans of pork and beans. Would that be acceptable?

  • “You know, one of the things we didn’t talk about was all the things around salary. Stock options, bonuses, vacation days. What can you come to the table with here.”
  • “I think that goes a long way towards closing the gap. I really appreciate your flexibility there, because I am committed to this role, and options are a great way to demonstrate you’re committed. What would the review cycle be for my performance as far as evaluating my candidacy for a promotion and a raise? My understanding is that it tends to be a year, ”

 

Other links:

 

TCP/IP vs Named Pipes Connections in Your Application

Recently faced an issue in connectivity where the SQL box was taking 5 seconds to do basic things like opening up a connection, etc – one fix proposed was to change our connection from TCP/IP to Named Pipes. Was this a correct choice?

This blog article echoed the statement from Books Online: “Generally, TCP/IP is preferred in a slow LAN, WAN, or dial-up network, whereas named pipes can be a better choice when network speed is not the issue, as it offers more functionality, ease of use, and configuration options.” The author noted issues where the application would periodically disconnect from the database; and unlike TCP/IP, the app wouldn’t fail gracefully or attempt to reconnect. Named Pipes doesn’t support Kerberos, only NTLM.

This article also favored TCP/IP over Named Pipes for these reasons:

  • For small to moderate amounts of database traffic that aren’t heavily saturated, it doesn’t matter
  • Where connectivity is strained or there’s additional routing overhead (i.e. VPN) then TCP/IP has the advantage – esp where applications are chatty.
  • Named Pipes connectivity always uses more packets to get the same amount of work done with remote clients.
  • Named Pipes has a significant advantage when running an IIS app on the same box as your SQL backend (?!?!)