Select the best cloud storage solution for your Mac business
By Erik Eckel on 2015-08-23
Numerous cloud storage options are now available to Mac businesses. Here are a few quick tips on selecting a cloud partner matching your business needs.
Small multiples vs. animated GIFs for showing changes in fertility rates over time
By Randy Olson on 2015-08-23
data visualization, fertility rates, GIFs, small multiples
A couple weeks ago, Stephen Holzman shared an animated GIF on /r/DataIsBeautiful that caught my eye. The GIF showed the evolution of fertility rates of the U.S. and Japan between 1947 and 2010, which starts right in the middle of…Read more ›
OpenStack's newest sugar daddy looks to private cloud to save its bacon
By Matt Asay on 2015-08-24
Intel just went big on OpenStack, but not out of a love of freedom.
#NoHacked: Fixing the Injected Gibberish URL Hack
By Google Webmaster Central (email@example.com) on 2015-08-24
Today in our #NoHacked campaign, we’ll be discussing how to fix the injected gibberish URL hack we wrote about last week. Even if your site is not infected with this specific type of hack, many of these steps can be helpful for fixing other types of hacks. Follow along with discussions on Twitter and Google+ using the #NoHacked tag. (Part 1, Part 2, Part 3, Part 4)
- Temporarily Take your Site Offline
- Treating your Site
- Identifying and Fixing the Vulnerability
- Next Steps
Temporarily Take your Site Offline
Andrew Koenig first coined the term "antipattern" in an article in JOOP, which is sadly not available on the internet. The essential idea (as I remember it ) was that an antipattern was something that seems like a good idea when you begin, but leads you into trouble. Since then the term has often been used just to indicate any bad idea, but I think the original focus is more useful.
In the paper Koenig said
An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one. -- Andrew Koenig
A skeptic's look at ClearSky's storage array replacement
By Keith Townsend on 2015-08-25
Cloud-based storage startup ClearSky is making a bid to replace your on-premises storage array. Keith Townsend breaks down his concerns about the approach.
You're doing cloud wrong: 99% of companies aren't optimized, says new study
By Conner Forrest on 2015-08-25
A Cisco-sponsored study by IDC said that the second wave of cloud adoption is imminent. However, it indicated that most businesses aren't taking advantage of cloud the way they should be.
How to recover deleted iCloud data
By Cory Bohon on 2015-08-25
iCloud is a great place for storing data to be synced between multiple devices. However, if you lose this data, it could be devastating. Find out how to recover deleted data through iCloud.
One of the most common ways to modularize an information-rich program is to separate it into three broad layers: presentation (UI), domain logic (aka business logic), and data access. So you often see web applications divided into a web layer that knows about handling http requests and rendering HTML, a business logic layer that contains validations and calculations, and a data access layer that sorts out how to manage persistant data in a database or remote services.
On the whole I've found this to be an effective form of modularization for many applications and one that I regularly use and encourage. It's biggest advantage (for me) is that it allows me to reduce the scope of my attention by allowing me to think about the three topics relatively independently. When I'm working on domain logic code I can mostly ignore the UI and treat any interaction with data sources as an abstract set of functions that give me the data I need and update it as I wish. When I'm working on the data access layer I focus on the details of wrangling the data into the form required by my interface. When I'm working on the presentation I can focus on the UI behavior, treating any data to display or update as magically appearing by function calls. By separating these elements I narrow the scope of my thinking in each piece, which makes it easier for me to follow what I need to do.
This narrowing of scope doesn't imply any sequence to programming them - I usually find I need to iterate between the layers. I might build the data and domain layers off my initial understanding of the UX, but when refining the UX I need to change the domain which necessitates a change to the data layer. But even with that kind of cross-layer iteration, I find it easier to focus on one layer at a time as I make changes. It's similar to the switching of thinking modes you get with refactoring's two hats.
Loosely Coupled Tests
Test Driven Development (TDD) has a plethora of benefits, but the one that stands out for me is how it helps to unify a team. This is because the outcome of TDD is a code base with high test coverage that acts as a safety net for future changes.
However, there is a risk that this safety net can become too tightly entangled around our code. For example, overusing mocking libraries or unit tests that are too knowledgeable about the code they are checking can in fact make the code more cumbersome to work with. Because software is in a perpetual state of flux—either due to new features being added or issues with the current code being addressed—our tests need to allow for change.
One of the fundamental axioms of object-oriented programming is that a set of objects work together in order to achieve a particular goal. This has a profound effect on how we do our testing. When we are writing a test for a class
X that depends on class
Y, then the unit test for class
X also needs to be aware of this dependency.
Program Like a Debater: Character, Commitment, Team Work, Hard Work
During my time as a debater, I had the privilege of working under the greatest coach in the history of college debate: Larry Scott Deatherage. Most of us who knew him referred to him affectionately as "the Duck."
Duck coached seven national champions in 12 years. Across his tenure, he personally led Northwestern to more national championships than any other program in the history of college debate—Harvard, Dartmouth, Berkeley, you name it.
He instilled in me the mantra from this blog's title: character, commitment, team work, and hard work. It was a set of principles he referred to often; a collection of foundational building blocks upon which success in debate is built.
As I've been growing as a software developer, I've been keeping an eye open toward figuring out what sorts of principles underlie success in this discipline. I've pursued the topic in conversations with colleagues, and checked for clues in the books that I read.