Smudge

Believe it or not, there are still people in the world who are victims of violence, abuse, and/or hatred, for whom revealing their legal name, or allowing their online identities to be revealed in searches for their name, might mean putting themselves in unnecessary danger.

So, by this versioning logic, Microsoft would also have to skip Windows 70-89, and many versions after 99, since 10-69 and 90-99 would be used by that time. They'd also have to skip 95 and 98, of course.

Am I missing any other versions, or can we expect 11, 12, 13, etc (all the way until 69)?

Yeah, my intent is not to overly praise that particular department, as much as highlight the difference in their mission statements. Whether or not they adhere to those is another thing.

I understand the distinction and the philosophical differences. The USFS and USDA are, overall, a good thing for us to have, and they clearly serve a different role from the National Park Service, et. al.

That said, having seen first-hand an example of "low-impact recreation", I felt that the USFS was over-stepping its bounds. There was even a recent investigation by the Government Accountability Office on whether or not the USFS should be moved from Agriculture to Interior[1], the result of which seems to have re-enforced the cultural differences these two departments have had since their founding.

But I'll admit that the case of the RVs and dirt bikes might have been an outlier. I was simply not impressed by what I saw, and I hope that it's not happening much elsewhere in our national forests.

[1]: http://www.gao.gov/products/GAO-09-223

I don't doubt that Crossfit does a lot of good, but after reading this I decided not to try it personally:

https://medium.com/@ericrobertson/crossfits-dirty-little-sec...

https://news.ycombinator.com/item?id=6424280

I recently tried to go hiking in Colorado with my dad in an area that he remembered being a great hike ~20 years ago. Well, we get there, and we realize the majority of the area has become an RV camp littered with dirt bike trails, despite it being managed by the National Forest Service. We still had an okay time hiking once we got to the main trail, but the whole area around it was a dust bowl, certainly not helped by all of the erosion.

As we were leaving, he remarked that this is what happens when your country's forest service is part of the Department of Agriculture (tasked with policy on farming, agriculture, food, and using resources economically) instead of the Department of the Interior (housing the National Park Service and the Fish & Wildlife Service, among others, and tasked with conserving federal land and resources).

It's a real shame that the Forest Service, while doing an okay job maintaining much of the land, is part of a wider branch that is incentivized to promote economic growth and treat resources as things to be used instead of preserved. It just doesn't seem to fit in with that branch of the government.

I'm probably dating myself a little, but this was true for me as well. Pre-college, everyone used AIM. During college, most social communication happened on email lists, with some 1:1 communication happening through the first version of google chat ('gchat'). As in, the one with the desktop client.

Really? This is definitely not true in my experience. Most startup employees I've talked to absolutely know that 1%, 10% 30%, whatever, of nothing (or practically nothing) is still nothing. They're not in it for the rare chance that their 0.5% or less earns them upwards of $1M.

One thing this methodology doesn't account for is company culture. It would be tough to predict in aggregate, though...

You could start by crawling for key words in job board posts. Companies that value, for instance, 'vacation', 'open source contributions', and '20% time' might (depending on who you are) be preferable to those listing 'nerf gun fights' and 'free beer' as perks.

Another idea would be to look at the age of the founders and early employees, as well as the schools attended. I don't have the data on this, but I suspect that a more diverse employee background would correlate with a stronger company culture. Then again, small companies will tend to hire within their personal networks, naturally selecting for people with similar backgrounds, so you shouldn't necessarily see a relatively homogenous company as a red flag, unless they are larger than ~10 employees and are actively hiring more. (Of course, if the company is very homogeneous but lines up with you exactly, that might also indicate a 'good' match.)

There are probably other ways to predict company culture, but ultimately you won't really know until you have a chance to visit their offices, meet the team, etc. But by doing a bit of research up front you may be able to narrow down your search based on a few red flags here and there.

Not if you upgraded to hangouts.

I've started combining both approaches, with help from SASS's '@extend' directive.

What I mean is, I have a section of my CSS for defining all of those simple, modular classes like 'button' and 'button-rounded' (I start with bootstrap for most of these and then add more as I need them), with the idea that I'll reuse these over and over.

BUT, these never get used in the HTML directly. Instead, I have a second section of my CSS which contains definitions for those high-level, one-time-use rules. So, for instance:

  // Low-level CSS (don't nest anything or it breaks @extend)
  .button { // basic button... }
  .button-large { // large button... }
  .button-rounded { // rounded button }
  .button-primary { // blue button }
  .button-warning { // red button }

  // High-level CSS (avoid nesting, but sometimes it is okay)
  #buy_page .buy_button {
    @extend .button;
    @extend .button-large;
    @extend .button-primary;
  }
  #settings_page .deactivate_button {
    @extend .button;
    @extend .button-rounded;
    @extend .button-warning;
  }

The big rule for the HTML is that I can only use IDs and classes from the high-level CSS, and should really only have one class/id per element. For the most part the high-level selectors are 1:1 with the markup, but things like widgets/components it's okay to reuse them on multiple pages.

The major exception here is the CSS for actually laying out pages. I don't use a class-based grid system. Instead, I map <section> tags to rows and <header>/<article>/<aside> tags to columns. The grid behavior is defined using Susy[1], and for specific pages I can modify the standard layout pattern if necessary.

The result of all of this is CSS that is easy to navigate. The low-level CSS is highly reusable, and the high-level CSS is structurally similar to page content, yet keeps the presentation information entirely out of the HTML. It also sometimes results in very long selectors, but that's actually not an issue performance-wise and has yet to cause me any issues.

[1]: http://susy.oddbird.net/

Yeah I'll second this. You can also use the @extend directive to make selector definitions inheritable (kinda), in the case where 'rounded' and 'large' do have to be classes.

  .buy {
    @extend .large;
    @extend .rounded;
  }

I should never have to use .large and .rounded in my HTML directly, but I might use both a 'buy' and a more specific 'buy-special-case' which itself @extends 'buy'.

> or disproportionately benefit parts of the population

Wouldn't more people be able to afford internet access under this municipal connection's pricing than under Comcast/Verizon/Time Warner/etc? I have trouble understanding how that would be a disproportionate benefit.

Does your `.dev` container access conflict with users of pow.cx? Is that configurable?

Yeah I found that loading indicator bizarre. What am I waiting for? Is it circumventing the browser's rendering engine and doing it all in canvas or something? (I mean, I know it's not, that would be silly. It's more likely having to make multiple network requests to fetch the rest of the content.)

I can understand the other javascript-ey bits as forgoing some amount of UX/usability in exchange for flashier visuals. But the loading indicator on initial page load just doesn't make sense to me.

I'm interested to hear you back up that point about modularity coming naturally in functional languages. Not because I don't believe you -- I've worked with both Haskell and Scala and found both quite refreshing. But I've also encountered codebases on functional languages that are just as muddy and rigid as some of their OO counterparts... So I wonder how much of that modularity is actually a result of the language.

Pshaw, those were just some protocols built on top of a network.

I consider the $100/hr designer and the Fiverr designer in two entirely different markets. At the low-end, you get what you pay for, which is not much. But sometimes you don't need much. You're not really taking business away from higher-paid designers.

That said, as soon as you need any kind of ongoing relationship with someone who can seriously transform the design & aesthetics of your product into something competitive, the value of the high-end designer becomes immediately apparent. $100/hr might even be cheap, depending on your needs. It's just an entirely different market.

In order to be world-changing, Facebook and Twitter don't have to fundamentally change the way humans communicate and organize into movements. Because they don't -- as you pointed out, humans have followed these patterns time and time again, all throughout history, and nothing about social networks has fundamentally changed this. But that doesn't mean they're not world-changing. Simply amplifying our capacity to communicate and organize around ideas is a huge leap forward. What used to take months or years to reach a critical mass could, on today's technology, take days or even hours.

I think you're really onto something when you say that "current movements are much more tamer and less populated" than seen historically. I'd theorize that current movements are happening sooner and in smaller spurts largely because social networks lower the required breaking point. It's easier than ever to organize around a perceived injustice, so what once would have grown and festered until it reached a huge breaking point now only requires a single viral video to draw crowds.

By that argument, no individual product or platform is truly important because everything is just built on what came before. Things that seem truly revolutionary are, more often than not, incremental changes on previous ideas that were easier to miss. As such, many movements and uprisings may be largely inevitable, and probably aren't the result of individual products like Facebook and Twitter, because they could've happened without them.

But that line of thinking is COMPLETELY missing the forest for the trees.

The world changes exactly because of such products -- specifically, because of the confluence of every idea and product up until that point in history. The Arab Spring may have been largely inevitable, but it was spurred by everything leading up to it, including the advent of social networks as a new communication platform.

Interesting perspective. It's unfortunate that you can get bit even when trying to play fair. Even if LinkedIn's mistake was similarly unwitting, we should try to learn something from it. Maybe the rules have become too complex, or maybe more guidance is needed to help employers stay within the lines.

> The DOM was filled with things like “ng-click” which reminded me of the spaghetti age of HTML and Javascript.

This was actually my biggest complaint, and still is even after learning to use Angular and Backbone. It always feels like I'm conflating view rendering with data binding, when in my mind those are two separate concerns. Lately I've been playing around with Facebook's React, which feels a lot more like traditional view rendering (but in a refreshing way).

The issue I have with ranking/review systems is that, more often than not, they become self-fulfilling prophecies.

A negative mark will change the way a manager perceives an employee. The employee's positive contributions will suddenly be subject to greater scrutiny, and slip-ups will serve only to reinforce the manager's confirmation bias. Similarly, an employee's confidence and sense of self-worth can be shattered by a negative review. It's suddenly very easy to feel like no matter how hard you work you won't be valued by your managers and peers. All of this leads to a negative spiral of career-choking doom. I've seen it happen to friends and coworkers, and it's very sad to watch.

If you're going to evaluate your employees based on their relative performance, it's critical that they have the freedom to change their situation, without repercussion. Allow them to change teams or roles freely, until they find a role that really amplifies their individual strengths. (After all, you hired them for some reason, right?) I've seen companies make the mistake preventing an employee from changing teams until they demonstrate they can improve their performance. Of course they can improve their performance, but only if you let them move to a better role!

Instead of treating poor-performing employees like cogs that simply need to spin faster, I wish more companies recognized how varied and diverse their employees are, and how a productive workforce needs to be cultivated and maintained, not bought and hired.

> This company has shown a great deal of integrity by fully cooperating with investigators and stepping up to the plate without hesitation to help make workers whole ... We are particularly pleased that LinkedIn also has committed to take positive and practical steps towards securing future compliance.

I'm surprised they're getting praised so much for complying. It's not like they had a choice.

Instead of commending them on their newfound diligence, we should be asking why and how these overtime violations occurred in the first place. Was it a systemic problem with lower management incentives? How far up did knowledge of the violations extend? Why wasn't it detected until now, and what can we do to prevent it from happening elsewhere, not just within LinkedIn?

Crunchbutton (.com) started as something similar (originally called "One Button Wenzel", named after a sandwich famous on Yale campus). It's an interesting idea, and might be particularly suited to orders like pizza, which are predictable and repeatable. Unfortunately in crunchbutton's case, the novelty wore off pretty quickly. I'm surprised to see that they're still around, given how few locations they serve.

Use the right tool for the job. If accessing a meaningful subset of your data requires 14 joins and returns 600 attributes, your data model probably isn't going to be friendly to many ORMs. Just write the SQL, maintain the sprocs and tvfs, and give up on trying to fit everything neatly into an object-to-table mapping.

But if you're tired of rewriting the same, CRUD-like SQL over and over again, and want a common framework for accessing similarly structured data, you'll inevitably write an ORM (however minimal) and then you're facing the same problems that every ORM has attempted to solve to date.

The biggest danger in using an ORM is that it will constrain how you structure your data model. It took me a long time to become comfortable with using (materialized) views to back my models, or using multiple models for a single table. But being able to divorce my data model from my conceptual model has helped me immensely, in terms of avoiding a lot of the problems the author is talking about. Rails' ActiveRecord is surprisingly friendly when it comes to these sorts of things.

Preprocessors often have prefix support baked in. It's not about explicitly testing your site for backwards compatibility. It's about casting that net as far as possible with minimal effort.

The trick is to make those 4 hours as productive as possible, so the rest of your day can be spent on more menial tasks. Finding the right balance comes with time and experience, so I wouldn't stress about it too much.

Sometimes people claim they can be productive for 8 or more hours per day, for weeks on end. But likely what's happening is they are tricking themselves into feeling (and looking) productive, while their actual productivity finds an equilibrium far below what it could be if they paced themselves.

That query means nothing. Most of those results include the non-prefixed version as well. The prefixed one is there for backwards compatibility.

I'm a fan of using the right tool for the job. If you can't use git effectively or it just doesn't fit into your workflow, then, hey, don't use it.

But, having used both, I'd actually like to know... Why are these things (that the author is claiming git can't do) so important? For instance, is checking out a partial tree ever necessary? Is it that you'd want more granularity over what subsets of the repo you are storing locally? Is it that you don't want to have to set up a bunch of (sub-)repositories?

I ask because... I once worked on a codebase that was so absurdly huge most of us couldn't store it all on disk at once. And it sucked. Hard. I WISH it had been started as a bunch of distinct submodules, with extension points baked into the core build system so it would be easy to add/remove sections of the codebase. But the product predated git. And SVN for that matter. (Granted, the majority of the issues we suffered -- nightmarishly complex build systems, lack of transparency into what changes are being made, a bottleneck of devs lining up to commit changes -- were caused by process issues, not source control. But the source control did absolutely nothing to help either.)

I really understand the frustration when it comes to git. It took me a LONG time to wrap my head around why it works the way it does, because I wanted/expected it to work like SVN, where the repository is like a giant tree of files reflecting exactly what I see on disk, with different branches of code getting their own branch of the tree. Instead, git was this concise, magical pile of data structures that somehow kept causing me to break things whenever I strayed too far from a basic commit & push workflow.

But then I changed jobs a couple times. And, for some reason, I no longer found git a huge pain. In part because it just started becoming more natural and I knew what kinds of things to avoid, but also because I decided to sit down and really learn what I was doing. For one thing, I began making more active use of rebasing. Initially so I didn't need a ton of useless merge commits to keep up-to-date with the master branch, but eventually as a way of tidying up my work on a feature branch (i.s. squash, reorder, amend, etc) to make the set of changes concise and easy to follow. When working locally on a new feature branch, my commit log went from looking like this:

> okay one more try at part A [tests pass]

> fixing typo [tests pass]

> one last thing for part C [tests fail]

> part B bugfix [tests pass]

> fixing bug in part C [tests fail]

> finishing part B [tests fail]

> trying this again (feature A) [tests fail]

> part C, work in progress [tests fail]

> part A, I think [tests fail]

...

To this (more or less):

> part C [tests pass]

> part A (final implementation) [tests pass]

> part B [tests pass]

> part A (initial implementation) [tests pass]

...

Depending on who you are, you'll either love that, or you'll scream at my lying, revisionist git log before wrenching out your eyes and hurling yourself out a window. But, for me, for the team I was working with, and for the codebase I was working on, it worked WONDERFULLY. I found myself feeling like I really controlled the readability of my changes. Each of those commits could be submitted individually for code review with no problems, and even though I was wiping out a ton of minor changes, I could still preserve a record of alternate implementations in case we wanted to refer to them later.

Anyway, this post has become a long ramble. But, suffice it to say, I've found git to be very freeing. I just had to give up any expectations about how the process would work, and let myself start forming a new process around the power and flexibility that git offers. I believe I could say the same for mercurial (though I don't have much experience on it). And I don't think I can say as much for SVN, though I'm sure it does have a few advantages. And if you're workflow really can't change... SVN certainly works for what it is. It's just not something I'd ever like to go back to.