Smudge

Yes, I've seen this too. I think I've even been that person. (But that's a different story.)

The first company I worked for claimed that most new employees took 6 months to ramp up to the internal tools & processes, which sounded absurd to me until I actually started ramping up myself. Holy cow. And the people who were entrenched in this company's particular way of doing things seemed like absolute geniuses until I realized how much of their knowledge came from years and years of doing the same things over and over.

I think the best way to combat this is to recognize that tools, techniques, processes, and technologies are all an inherent part of your product and your business. Much like you take the time to refactor code and combat technical debt, I think it's pretty crucial to also devote time to combating "process-debt" and/or "tooling-debt" -- all of that extra cruft that piles up and starts becoming "the way" to do things at your company. Because, just like with code, there is usually a simpler, more practical and/or elegant solution just waiting to be discovered.

yes-www is clearly the more practical solution based on current technology and its limitations. And no-www (http://no-www.org/) is clearly the more aesthetic solution.

Either is perfectly valid, and depending on who you ask you'll get reasonable arguments in favor of both. That said, neither choice will ultimately make any difference. Period.

Even if your site becomes the next Google, the minor hurdles of a no-www domain vs the technical advantages of a yes-www domain will not make an ounce of difference. Anyone who tells you otherwise is straight up fooling themselves.

> This website is static, so it can be saved and loaded locally. Just right-click and "Save Page As.."!

This strikes me as particularly neat. I wish more SPA's were able to work like this.

Interesting idea, but right now this is just a self-hosted instance of Reddit, is it not? How do you plan to develop the idea further and (most importantly) attract actual visitors/users?

Surge pricing was a brilliant way to ensure the marketplace could deliver when demand for drivers was high and/or supply was low, but it's also an example of why a "free" market can really screw over individuals at the worst time, when they really need a ride the most, for whatever reason.

It's a tough problem to crack and you can sort of see any solution Uber offers to customers as a form of market regulation.

Looks like it is doing something with shields.io, but hard to know what to make of it without any real README. Also, some of the badges consistently fail to load for me.

Honestly, more like "the real reason to avoid programming"

If you are the type of person who likes to paint ideas and approaches in black and white, pointing out only the upsides of the things you like and only the downsides of the things you don't like, then you're going to REALLY hate programming.

Yep, domain looks parked to me...

You can access it directly here: http://204.246.150.204/

One thing I noticed -- the Nexus 6 actually comes in either 32GB or 64GB, but when I search based on memory/storage or on price, only the 32GB shows up. This is probably happening for other models with multiple variations. (Also, I think the price you've listed for it is just wrong -- likely due to limited supply on Amazon)

I suspect that Obnam doesn't cause all of the de-duplicated chunks to get so "entagled" (as bup puts it, in their readme).

There are existing discussions about the way bup pruning would have to work:

https://groups.google.com/forum/#!searchin/bup-list/prune/bu...

Sounds like they are actually making progress on it.

I can see how this would be theoretically possible in the same way I could see using `git filter-branch` to remove one or more commits from a code repository. But as it requires walking back up the tree to recalculate all of the commit hashes based on the new state of your files, I suspect it would be an extremely slow/expensive operation in bup's case. Someone who knows more about bup's internals can correct me if I'm wrong.

I use this Ruby version:

https://github.com/daddyz/phonelib

No. Some view layers require you to specify a lot more of the state transition code and may be more heavily integrated with the rest of your architecture (like the way you do data binding, etc). Because React transparently updates state by simply re-rendering components, you can keep it very cleanly decoupled from the rest of your architecture. There are other frameworks that accomplish similar tasks, but I've found that none come quite so close to having zero lines of state transition code as React. (In React, most of my state transition code involves visual animations.)

It depends on the location of the observer. (coming towards you = blue, moving away from you = red)

The most interesting part of this release (well, something that came shortly before this release) is Bootlint, their linter for your bootstrapified markup.

https://github.com/twbs/bootlint

I could see myself integrating something like this into a text editor or a build process -- something that watches for bootstrap usage errors and helps my team correct them early and quickly. That is, of course, assuming that we stick pretty closely to vanilla bootstrap, which we usually don't.

One of my biggest issues with Bootstrap (and similar frameworks) is that, beyond a certain point, you find yourself overriding and customizing them to such a degree that it's more productive to just build your own "vanilla" components that are specific to the way your site or organization uses them, and then just ditch Bootstrap altogether.

One thing I'd like to see is a way of generally linting HTML structure (not validity, but actual structure) with a goal of reducing complexity and improving maintainability, regardless of what frameworks you may be using. Something that spits out a ratio of meaningful, semantic markup to "div soup" and tells you where you should spend the most time mopping up the soup. It could also have some understanding of which kinds of div patterns are acceptable -- bootstrap components, your own component library (see: OOCSS), etc.

I find that "progressive enhancement", while perhaps a bit more work, results in a more robust and maintainable webapp. The fact that results in pages that work without JS is almost a side-effect and barely needs to be tested.

The point for me is that links behave like links (perform GET requests against a URL and change the page from one state to another), buttons behave like buttons (perform POST requests and update some internal state), and the effect they have on the page is much the same with or without Javascript. The only difference is that with Javascript I can intercept the action and make the state change a lot more streamlined, or add a fancy animation if I so desire.

By simply intercepting buttons and links (similar to how pjax and turbolinks work) I don't have to dig through JS to find where a specific AJAX request is fired-off and what it does. It just works, and when it returns, it simply updates part or all of the page with whatever the server returned, which could be part or all of a page.

There are, of course, obvious limitations, like local state that changes with user interaction but that isn't preserved on the server in any way. But the more I can get working without Javascript, the more I know will be easily maintainable and translatable going forward even if I do something crazy like get rid of jQuery or convert everything to a React app.

Maybe I'm just a bit odd, but I find this approach a lot easier to manage and a lot more productive in the long run than in marrying myself to any particular client-side framework.

Fair. I haven't tried rendering server-side with React. I'm sure it's as much a maintenance nightmare as much as any major feature.

But I do have apps I maintain that started as traditional Rails apps and have been progressively enhanced to a point where they perform a lot like more modern client-side apps. And an interesting property I've discovered to be true of such an app is that it's really quite easy to convert that traditional view-rendering pipeline to React, because there is almost no JS-soup being relied on for core pieces to function.

On the flip side, I also work on a couple apps where most of the functionality exists as JQuery DOM manipulation or as Bootstrapified data binding, and these are nearly impossible to port to a diff-based rendering library like React without rewriting most of the functionality.

So while I haven't exactly tried rendering React on the server, I've found that the more traditional server-side rendering flow still holds up quite well on the modern web. It's a good way of thinking about how your app should look/behave given a set of states, and it holds up well even in places where Javascript is required. The fact that it can be accomplished without Javascript is more of a side-effect, but also a good indication that it's not any particular bit of Javascript that is holding it all together.

There are non-Chrome-specific "offline" APIs. Some already found in the wild, and some still exist as specs. Google is free to roll their own and keep it to themselves, but I think it's perfectly okay to shame them when they do. It's the same reason I was against ActiveX components in IE. Theres nothing fundamentally wrong with a company pushing things that align with their interests, but there's also nothing wrong with complaining about it like this Tumblr blog does.

Whatever happened to "progressive enhancement"? It's possible to build a very rich experience around standard HTML+CSS and then enhance it with Javascript. This is how much of Github works. I'm not saying you should always take that approach, but if you're a small company with limited resources you can still choose which route you want to go down, and if you choose "progressive enhancement" then you have a site you know will (mostly) work without JS, without having to do any extra work on top of you usual development process. Rich companies can, of course, take both routes, but if you're going to build a javascript-heavy site you should at least understand the trade-offs and alternatives before you dive in head-first.

You could always just build one version that is capable of rendering either server-side or client-side. React.js and other similar frameworks (that do diff-based updates) work well with this, or at least better than frameworks where the state changes are discretely coded.

The react-rails gem is capable of doing server-side rendering out of the box: https://github.com/reactjs/react-rails

I guess it depends on what you mean by 'works' -- I was able to view my facebook profile, click on links, visit other profiles, and even view a few entries on my news feed. Same with Twitter -- profile, news feed, a few other pages. Posting is broken, certainly, but to do that on Facebook I could click on "switch to our mobile site".

As someone who also enjoys building rich interactions as well, I find that it's just a matter of understanding the trade-offs.

Requiring Javascript support is sort of like relying heavily on the latest HTML or CSS features (a recent example: WebRTC). I have to consider what happens in browsers where the feature is unsupported or disabled, and if I'm okay with narrowing those visitors out of my userbase, then I move forward. Otherwise I make sure that something is in place for them to fall-back on.

Javascript is a bit tricker than, say, the fancier CSS selectors, because I often rely on Javascript for polyfills/webshims, etc, and you can't polyfill a lack of Javascript. But when I can I still make use of that old "progressive enhancement" idea by starting with the basic HTML/CSS elements required to make a feature work, and then enhancing it with Javascript and more modern styling. It doesn't work everywhere, and certainly not in cases where most of the work is done client-side, but I still get plenty of miles out of that technique.

You might be surprised at what can be accomplished with HTML and CSS alone. Most of github.com works just fine without Javascript. Much of Twitter and Facebook work too. Facebook does give a warning, but they say you should enable Javascript "for a better experience" instead of "for any experience."

I agree that showing a "hey this is broken" warning is better than rendering a totally broken page, but it's still not as good as presenting at least a partially working version, perhaps minus all of the usual bells and whistles. Now, of course, this is not super-feasible if you've chosen to build most of your site using client-side code, especially if that's where most of the rendering happens. But then again, the lack of server-side rendering is the obvious downside of building your site that way.

I like taking my time too. The best solutions come to me after days or weeks of chewing on the problem in the back of my head.

Experienced interviewers know that this is how people solve problems. They know that time-boxing the problem is artificial, so they're not exactly evaluating you on how fast or slow you are within that time. The problems should be constructed in a way that lets them evaluate you based on your approach instead of on your solution.

Sometimes it's just a bad interview question, or not the right question for you, the interviewee. Which is why interviewing takes practice, time, and patience, from both sides of the hiring market. It's far from perfect, but more "puzzle"-like questions aren't entirely useless as long as the interviewer really knows what they're doing and how to guide the interviewee.

> Could you please solve this algorithmic puzzle within half an hour? I failed. Hiring decision made. End of story.

If that alone was the reason, then your interviewer did a bad job.

The point isn't to trick you. It's to see how you work under pressure when presented with a tough problem. What is your thought process? Do you dive right in or do you take time to chew on it? What parts of your background can you draw on to help you?

It certainly helps your chances if you can solve the problem, all else being equal, but I'd rather take someone who talks through their work but doesn't quite solve it over someone who solves it yet has trouble explaining how or why.

The best interview questions are layered. There should be a relatively easy solution solvable in multiple ways by anyone with experience programming. It should almost solve itself if you walk through the specifications. (Think fizz-buzz-level.)

But underneath that should one or two harder problems with very elegant solutions. And those are much more about the process -- about weeding out the people who would dive in without really thinking it through. If you make a mess of the whiteboard, get frustrated, start desperately erasing and rewriting the same things without ever stepping back to think through alternatives... well, that might be what I'd hold against you. It's not that you didn't solve it. It's that you didn't prove to me you could've given more time.

I'd argue that being able to think laterally across multiple parts of the web browser is much more important for front-end development than having the typical CS background (algos, data structures, etc).

But the CS background certainly doesn't hurt. Especially when it comes to stepping back and figuring out how to do the same stuff with less code (i.e. making good architectural decisions and finding the right frameworks for the job), instead of diving straight in and producing a giant mess of code, which is quite easy to do on the front-end if you're not careful. (Especially if you throw JQuery in the mix -- at that point you have a hearty soup of DOM manipulation code.)

No, I get it. I was just extrapolating, since presumably devs are still checking if the name starts with "Windows 7", "Windows 8", etc. But maybe they're not. Either way, if it's the user's problem, it's Microsoft's problem.

The line between being trans and being a "drag performer" is way more blurred and way more personal than you are making it out to be.

Furthermore, looking at your other example, I'd argue that PartyBro045 and BusinessDude75 should totally be allowed to present themselves as different people online. It doesn't get the same level of attention because It's unlikely someone will go after BusinessDude75 if his party identity gets revealed (at least not in the way many LGBT people face) but, hey, he might lose his job, which would certainly suck.

It think it's pretty easy to make the policy consistent. Identify bad actors not by the name they choose, but by whether or not the identity they present is "real," based on patterns of behavior. If they're a bot or a scammer, it shouldn't matter what name they use, real-sounding or not. Otherwise, leave them alone.

The issue of real name policies has come up many times before, most noticeably with Google+. From what I've seen, people tend to fall into these three camps (guess which one I fall into):

- I don't get it. Why does it matter. Just use your real name. It makes everything easier for the rest of us.

- I get it. Pseudonymity is important. But it's not worth the added noise / decreased quality on this site, so take it elsewhere.

- I get it. Pseudonymity is not only important, but something that should be freely available to anyone who wants to participate in this service. We all have different identities depending on context, and not everyone maps their legal name to all (or any) of their identities, so let's be sure to make room for those other identities too.

That's obviously an overgeneralization. But the response from camp #3 is definitely what caused Google to backtrack. It's interesting that Google's policy (only permitting your legal name or something close to it) was originally more draconian than Facebook's, who seem to only care that the name you use is the on people would know you by in "real life."

drag personas != standup personas, unless you're promoting your drag identity as a business (?)

I'd equate it more to simply having multiple identities. Some people know you as John Smith. Others know you as Sister Roma. When they try to find you on Facebook, maybe you don't want the two linked in any way. Why should John Smith be managing a business page called "Sister Roma" (or vice versa)?