I posted a blog post today on the Higher Logic User Group (HUG) blog about our Widget Builder, which was the first thing I shipped since joining Higher Logic.
Since then, I’ve shipped a few internal tools, but I’ll never forget my first [publicly] shipped software.
If I could give one piece of advice to a new programmer that would give them the most bang for the buck, it’d be:
Do One Thing At a Time. Do it Well.
If they were to learn nothing else; they’d still be ahead of the game by learning that.
I wish I had learned it sooner.
Objections to SOLID principles (Overheard through the years):
“Why should I have to click “Go to Declaration” on four different methods to figure out what happens?”
“I don’t see how refactoring the code adds business value.”
“We have to move faster; SOLID doesn’t let us do that.”
“All these small methods make it hard to find the code I want to change”
“It’s just a user control. It’s too much work to move the Database logic out!”
“I don’t understand the problem. Why does it matter if the ASCX is big?”
“Using Exceptions for flow control is just how it is; we can’t change it, it’s too brittle.”
“Be careful of making changes; we have customers depending on this code.”
“Fix that for new code going forward, but there’s no sense in fixing the code now.”
“Does it really matter that business logic is aware of the ASP.NET pipeline?”
“What’s an interface? I don’t see how that’s useful.”
Complaints (about the code):
“This code is hard to change.”
“I’ll work the weekend to fix this issue.”
“CODE FREEZE. Don’t check anything in for the next two weeks, so we can test everything.”
“It’d be really nice if it didn’t take so long to build the solution.”
“This code doesn’t make sense, it does too much!”
“We should put in more process to be sure code with bugs doesn’t make it into production.”
Design can be fixed. Code can be refactored. Improving the design of code is like Pascal’s wager: even if you lose, you win. If you hear complaints about improving code, listen for the complaints about the code as well: They’re intertwined.
Author’s Note: All of these objections to SOLID can be attributed to multiple people, some senior, some junior. I’m not calling out any one company or team or individual: This is an endemic problem in our industry.
Bonus: On Hacker News today, a similar story titled “Worse is Better” is making the rounds.
I opened up my inbox to see the following email from Glassdoor:
Before this email, I didn’t realize I had an account with Glassdoor, so proceeding to their site (and then resetting my password), I found that I did.
I started to peruse their Terms of Service, and I noticed this line (screenshot):
12. Termination
These Terms remain in effect while you use Glassdoor and, for Members, as long as your account remains open. You may delete your account at any time. We may suspend or terminate your account or your access to parts of Glassdoor, without notice to you, if we believe that you have violated these Terms. All provisions of these Terms shall survive termination or expiration of these Terms except those granting access to or use of Glassdoor. We will have no liability whatsoever to you for any termination of your account or related deletion of your information.
I can delete my account? Great! But how?
In “Me” menu, there appears to be only one applicable option: Account Settings:
Clicking on it, I see this screen:
Unsurprisingly, there are no options to delete my account on that page.
I contacted Glassdoor yesterday and again today about deleting my account. Let’s see if they respond. At first blush, however, it seems like Glassdoor is Hotel California.
Bonus: Googling for Hotel California brings up that at one time, Hotel California was taken as a song about Satanism.
Update: Deleting your account is a manual process (although they never tell you that, or how), but If you contact Glassdoor and ask them to delete your account, they will:
Plot twist: Tesla wasn’t arrested for unveiling the D.
Update 1:
CNN has changed the sidebar text:
But the article still maintains the “D”:
Is it really that hard to call it the “Model D”, or “Tesla D”, CNN?
Alternate Theory: Elon Musk is trolling the media by naming it “The D”.
A developer recently skype’d me out of the blue and asked me what ‘best practices’ would make them a developer.
Make Things. Ship them.
Everything I’ve learned as a developer has come from making things and shipping them. In my professional life, I’m batting about .700 for shipping. In my personal life? .250.
I have plenty of projects in various stages of completion, but none that are actually finished. I get to a certain point and just stop working on them. Here are just a few projects I haven’t finished:
Edit It: An editing tool for Stack Overflow that flags the most recently asked questions that need the most editing work. It uses an editing score to determine which ones need help (misspellings, grammar). It uses a spelling module and the Stack Overflow API.
Stack Stats: If your Stack Overflow profile page looked like BF2s.com (anyone else remember BF2s.com?)
JSTrek: A JavaScript clone of EGATrek.
OpenGrok support for TFS: (This one is actually ‘written’, just in the other 80% of programming: Debugging and testing)
Restore Gene fixes for AWS: Have you heard of Restore Gene? There are a few fixes I’ve made for that project, but haven’t shipped them.
Freelancer+: (think Uber for Tech freelancing. I know, pulling the uber card is a tiring meme, but who said I was original?)
Out of all these projects, I’ve learned a little; but I’ve always stopped before the crucial learning moment: Before shipping them. Before making them real in the eyes of the outside world. Fear sets in. What if it sucks? What if people don’t like it? What if nobody cares? How can I be good enough? I’m not a real programmer.
Every project that has propelled me forward has been a project I shipped.
I learned Perl through maintaining and shipping 10 websites in 10 weeks that used Perl as their backend.
I learned C# and Winforms through creating and shipping a rather crappy tracking system in college during my senior year co-op.
I learned ASP.NET MVC by shipping not one, but two versions of a CMS. One is no longer in use (the maintenance programmer decided to go a different direction), and the other I’ll probably scrap for WordPress, but they’re there. They were shipped.
I learned Python by shipping a CMS add-on for producing regularly updated content about Stocks.
I learned JavaScript and Angular by working with an awesome team to ship folios.fool.com, a portfolio management tool written in JavaScript with AngularJS and C# with NancyFX.
I learned how to be a DBA by saying “yes”, and taking over DBA Work. Now, in addition to programming, I’m quickly becoming a DBA (though more of an accidental DBA).
I learned how to be a dad by having kids.
Shipping teaches. You can program all day and night, but until that magic moment arrives when you ship, you haven’t taken the next step. You haven’t really learned.
I’ve only been at the DBA thing for the last six months. I’m as close to an Accidental DBA as it gets; and I’m the first to admit that. I’m learning fast, I’m learning on the Job, and (full disclosure), the Brent Ozar Unlimited team has helped with that, tremendously.
I’ve been following Brent Ozar‘s blog for a long time now, and more recently started paying attention to the PASS debacle(s). Before, it was idle curiousity, now it’s because I’m working day in and day out in that sphere. I can’t afford to be ignorant.
Today, Brent blogged about PASS’s lack of security surrounding their voting system. In essence, it worked like this:
PASS sends you to a third party site to vote, you input your PASS credentials on this third party site, and voila, you’ve voted.
See the problem? No?
How about now?
PASS sends you a postcard with an address to go to. You go to that address, give them identity information (Social, birthdate, whatever they need to act as you), and they mail it back to PASS with your vote.
Would you do that in real life? No. Then why would you do that online?
At first, it was fun and games. Everyone have a laugh at terrible security. Then, I took an action on the PASS site, and noticed that rather sensitive information was leaking out. I even dug into the developer tools to be sure I wasn’t making it up — but even after that, I still thought there was something I was missing. I had to be. I posted an offhand comment on Brent’s blog because quite frankly, I thought I was wrong.
I was so sure I was wrong that I didn’t even think about the ethics of disclosure. It didn’t cross my mind. I was hoping someone would reply with, “Hey, you’re not seeing X, or Y — they’re actually doing it correctly.”
So I posted a comment.
I shouldn’t have done that, because in this case: I was right. Oops.
I’m sorry.
Brent and others are already in contact with the PASS people to get this vulnerability fixed. For my part: lesson learned.
Note: If you’re trying to raise me on twitter, I’m taking a break from social media for the next 9 weeks. Catch me through a comment on this site or through email.
Additional note: If you have a link to a template for Responsible Disclosure that isn’t vendor specific, link to it in the comments. An internet search turns up a lot of separate “responsible disclosure policies“, but I haven’t seen an authoritative template on the subject that should govern our actions, or ethical actions in the case a company doesn’t have a policy on their site. Troy Hunt’s take on the subject is relevant.
Update 1: The vulnerability on the PASS site affects your user credentials (login/password). The site has been vulnerable for an unknown amount of time — but it’s not one of those things that work and you accidentally break one day. My supposition is that it’s been broken for a very long time. If you use the same username/email + password combination anywhere else, change it on that site immediately. ( I include email because that’s part of the sensitive information that leaks out, and some sites use your email address as your login instead of a unique username).
Do not change your PASS credentials until they fix the vulnerability on their side. Doing so will only cause you pain, without actually fixing the issue.
Update 2: You may wonder why this is a problem. After all, it’s not like it’s your bank, right? I mean, it’s just an association website! The problem is, that association represents professionals that have the keys to the kingdom in their own little world. Depending on what email address is used, a potential attacker not only has a company to target with user credentials, but potentially active directory passwords as well.
Good security practices are to use different passwords for each site; but how many people actually do that? I know I don’t always do that (though I do segment ‘non-critical’ sites from critical sites, and I use a different password for each critical site).
If this were a fantasy football site, I wouldn’t be as worried. However, this is a site where DBAs congregate — and in any revenue generating organization, the DBA sits right next to the goods.
Update 3: It looks like SQL Pass has purchased an SSL certificate and set it up. The affected pages are now being served over SSL; potentially negating the vulnerability.
Here’s how their SSL Setup rates:
If you use an SSL certificate (and you should, but that’s another story), it’s always a good idea to have a tool that can tell you where you’re vulnerable. The SSL Labs tools do just that.
I’ll be presenting at Hug Super Forum 2014; going on today and tomorrow at the Marriott Gateway in beautiful* Crystal City, Virginia.
I’m presenting on the new Higher Logic Widget Builder. It’s a way for you to take your Connected Community content and place it on any non-Connected Community site. For the techies amoung you, it’s a native-JavaScript powered widget (the temptation to use JQuery was strong, but the potential issues with compatibility clashes kept it from being the way to go)
I’m excited to be able to talk about something that has been in private beta for the past few months, and has the propensity to take content from behind the walled garden and make it possible for others to enjoy it.
I’ll also be talking all things tech at the tech table during open house at 3pm. If you have questions about anything related to your connected community site (tech wise, and even not so tech wise), we’ll be on hand to help you out.
*It’s an urban beauty.
Your homegrown framework is only as flexible as it is testable.
If you can unit test that framework without craziness, it’s flexible.
If you can’t, it’s not.
Even if I accepted that TDD and Unit tests were bunk for all other reasons, the fact that they result in a flexible design makes up for any other perceived flaws.
It also cuts through the bullshit. The next time someone tells you their code is flexible, ask them to write unit tests for it.
Bad software is an avalanche, waiting.
“We don’t need to worry about that for Version 1, let’s defer that to <version n>”.
“What can we get away with for what now?”
“Do we really need to worry about Cross Site Scripting? Who would want to hack us anyway?”
“Just get this bug fixed. Next time we build a new feature we’ll do it right.”
“Our customers don’t care about whether or not the software is good or bad, they just want it to be flexible.”
Once the avalanche starts, that’s it. There’s no going back. Sometimes that avalanche is launch day, sometimes it’s when the New York Times reviews your product. Sometimes, it manifests as the bankruptcy the company files because of a security breach.
You can get away with bad software for a while. But only for a while.
