Back in (gulp) 2008, I posted a simple design to keep raccoons out of the garbage and green bin. The design worked, I got some nice comments, and even a possible CBC TV spot on the design (which didn’t pan out, but it was nice to be asked).
[Inspired by a mail virus that’s going around, and the classic Strunk and White text, The Elements of Style]
DO NOT install random software from friends, links you get in email, ‘free’ screen savers, and the like. Less is better. Your systems will be faster and more secure, and you don’t need them. Even if they work, they are a waste of your time and system resources.
Here’s a longer aside for those of you who are thinking “But surely you don’t mean avoid installing anything?”
If you DO need something, do the research and get what you need for the time and money price you are willing to pay. (Free isn’t necessarily what’s best for you; the ‘more expensive’ package can easily be better for you in the long run.)
Here are a couple of relevant examples:
1) Web browsers: Firefox, Safari, and Chrome. Great web browsers, all free, and worth the minor work to keep them up to date. They all have their strengths; I use Firefox most often, but both Safari and Chrome for some other tasks. (Comments are more than welcome!) Sorry, I’ve been burned too many times by Internet Explorer to want to use it, and the other browsers support a wider range of machines, since Microsoft has dropped upgrade support for older Windows versions, and doesn’t support other operating systems. Your mileage may vary.
2) EVault data protection software. Yes, there are free alternatives, but for your business servers where you really, really have to be able to recover, these folks are really good. I’m no longer with the company, but I did run the engineering team for a year and a half, and I still happily recommend the products and services. The free/’freemium‘ alternatives are good as far as they go, but system restoration is tricky, and EVault gets it right. EVault software is owned, and the service operated, by i365, a Seagate company, so you know they’ll be around. Highly recommended.
I’d love to have comments on other ‘elements of security,’ so please feel free to chime in.
I had a conversation today with a former colleague about implementing mission-critical software, and the cost assumptions of Agile methods. He cited “Balancing Agility and Discipline: A Guide for the Perplexed” as an analysis which says Agile assumes as an axiom that the cost of change is constant (in the front end engineering processes, not in remediation, fixes in the field, etc.) Frankly, I suspect that’s because Barry Boehm is a classic “programming in the large” guru, but I haven’t read the book yet.
This is true (that Agile assumes constant cost of effort) in the sense that it’s held constant in the same sense of any other “assuming all other things are equal, we vary this.” I see the point, but it seems to me that it’s not true in practice, in my experience, but then, I don’t think many people implement Real True Pure Scrum or Lean or XP or any other agile practices; they typically implement some kind of composite methodology, which merges specifications and design artifacts in the outer feedback loops of (for example) Scrum.
But he did have an excellent…nay, *superb* point: without explicit architecture work as an input to software development, development frequently gets caught in a cycle of relative local improvement, without being able to leap beyond the limitations of the existing or incrementally developed architecture, and sometimes that just won’t get you where you want to go. I personally believe that these outer feedback cycles, including project kick-off, are the best integration points, and that most people practicing Scrum are working away with the “release and below” of the feedback loops, and neglecting release and multi-release planning entirely.
(I personally like the XP-style feedback loop diagrams on this page…to me, the architectural inputs belong in the outer feedback loop, with tweaking and involvement from the architecture team in the inner loops.)
To me, the point is that as software professionals, we have to be able to make decisions about what we’re going to build, buy, or integrate with, and this meta-decision can easily be a part of the Scrum, XP, or other Agile processes, and we don’t have to model the cost of the estimate purely by (for example) planning poker, especially when there are other costs involved. However, many organizations FAIL to make these decisions, instead always choosing to build, which leads to massive expense overruns, because they are trying to solve the wrong (software architecture) problem.
I’m looking forward to reading the book to see if it provides suitable guidance for practitioners in the field, both that I can use myself, and that I can reference to customers and employers. I generally find (both when working directly for an organization, or as a consultant) that some kind of ‘made to fit’ methodology is what’s really needed…and I haven’t seen that codified. Might have to do it myself, we’ll see.
Comments, insights, or experience are always welcome. More later after I read the book; I’ve always enjoyed Boehm’s work, so I’m looking forward to it.
It’s just an off-the-cuff observation, but: although global warming is accurate, it’s a completely unhelpful observation. The real ‘hits you where you notice it’ change is ‘climate change.’
This week’s climate change notice: Major snowstorms on the east coast of the US (‘Snomageddon’), and not enough snow for the winter olympics in British Columbia, Canada. While the real Great White North is somewhere between Ontario and Quebec, it’s still waaay up north.
It’s climate change; yes, it’s real, and no, there’s not enough data to accelerate bizarro multi-billiion-dollar government driven economic compulsion that North Americans should just stop driving cars.
Let’s keep our eyes on what the real issue is folks: we want to have better lives. Fossil fuels are just another kind of leverage, specifically potential energy leverage. Leverage for human effort is what makes us rich.
There are two excellent ideas in this posting on ZDnet, aside from the observation that you can scale Ruby on Rails if you avoid hitting the disk farm for static content:
1) Have a team devoted to rapid scalable prototyping. (LinkedIn Light Engineering Development)
2) Use free apps for both proof of concept testing and marketing.
Read and enjoy.
Ruby on Rails: scaling to 1 billion page views per month by ZDNet‘s Dennis Howlett — While a lot of attention has been focused on Twitter with questions about whether Ruby on Rails scales, LinkedIn has been quietly running a RoR application on Facebook that is beating down around 1 billion page view per month. Bumpersticker, a relatively trivial Facebook application that allows you to create a cartoon that you can […]
That’s today’s news, and I ran into it myself. All of the Canada Revenue Agency sites are Sllllllooooooooooow today. Moving the filing deadline off is the Right Thing To Do from a tactical standpoint. However, you still have to pay any owing amount today. (PUBLIC SERVICE REMINDER: do that through your BANK, the government’s website is too slow to look this information up there!)
This problem does raise some interesting questions.
Did they do volume testing, optimization, or load balancing? (Do you?)
Are their pages set to gracefully degrade in the face of large loads (clearly not; for the most part, the actual HTML (XHTML, a tip of the hat for a nicely structured page) loads, but the linked images do NOT), and the pages are set not to cache, even for purely presentational, ‘nothing to see that has changed here’ pages. (Do yours?)
Moreover, when you actually try to submit the ‘netfile’ .tax file, the page doesn’t load. The announcement that the deadline has changed is on a separate news page, that’s behind a submit button, and it too takes forever to load.
This is a solvable problem. Anyone care to weigh in on opinions as to how to solve it? I’ll do a follow-up summary and share some of my own thoughts later in the week.
Have you tested this sort of load with YOUR application? Does it matter?
(In my strong opinion: yes, it does matter, and you’d best be able to prove that your projected load is something you ARE handling, every day. You better also understand how your system will degrade under unexpectedly heavy load…like a million people clicking on the submit button multiple times because it didn’t respond fast enough 😉
I just read a helpful article about tuning organizational password policy but I’m afraid it rubbed me the wrong way.
What it says is helpful and mostly good practice, but it fails to address the problem from the perspective of the users, and does the usual “well, this will be a pain for the users, but it’s good policy, so we’re recommending it,” which is one of many reasons why people hate IT departments. (I say this as a seasoned IT professional, and I hate us, too. 😉
IF you notice that YOUR passwords violate any of these rules, chances are that they are already broken. Change them now.
To all password users, everywhere: Make your passwords unguessable as best you can. If someone guesses your password, change it. Corollary 1: Since you can’t know if someone might have guessed your password, change it from time to time. If you feel that you have to make a list of passwords, make a list of reminders, not the actual passwords, and keep it safe (not where someone can look at it without you knowing about it). More detail below.