Why I don't use CSS preprocessors - <AUTHOR> http://www.456bereastreet.com/archive/201603/why_i_dont_use_css_preprocessors <comment><USER3> Whenever I mention that I don't use compilers I tend to get strange looks from people who cannot imagine writing assembly with using a C or Fortran compiler. And so I have to defend my choice and explain why, over and over. Some people will understand, most won't. Or they don't want to. But here is an attempt to explain my reasoning.

[...]

A list of reasons then:

* I don't feel the "problems" compilers intend to solve are serious enough to warrant the cost, i.e. to me the solution is worse than the problem.

* I want absolute control of my instructions, which means I want to work hands on with it, and see exactly what will be executed by the CPU (well, before it's translated into its binary form, of course.) If that means seeing the same setup of stack frames and the manual register allocation over and over again, so be it. To me, WET assembly is much more understandable and maintainable than DRY C.

* I don't want to learn and depend on a non-CPU-vendor syntax for my programs, making it require compilation before CPUs can understand it. Neither do I want my colleagues to have to.

[...]

<comment><USER4> I'm always shocked when I run into people who use an assembler instead of interacting directly with their target hardware. If you're dedicated to your craft, you memorize the associated byte-code and enter that directly into the computer's memory. With practice, the machine will crash with less than 50% of your changes.

On a more serious note, the first computer I ever touched had six thumbwheels that were used to enter a memory address (4) and the associated byte to be placed at that location (2). The first computer I ever built/owned was a COSMAC ELF [1]. It (originally) had 8 toggle switches that could be used to enter the address and data (serially). In both cases, you still wrote assembly (on paper) and used a translation table to look up the associated byte-codes which you transcribed to the paper. Finally you actually entered it via the system's input.

[1] [http://www.cosmacelf.com/](http://www.cosmacelf.com/)

<comment><USER5> Why even rely on the machine instruction decoder implemented in your microprocessor? I prefer to hook up ALUs and flipflops manually...

<comment><USER6> That's a lot of work though, I just let the verilog compiler handle that.

</comment></comment></comment></comment><comment><USER7> Obviously the author should use whatever they want. But...the reasons given aren't in any way compelling.

> If my build process fails, for whatever reason (like an unpublished npm > module),

If you were unable to deploy because `left-pad` got unpublished then 1) you've got way more problems than your use of SASS, 2) not using SASS would not have helped you because you're build process is still broken, and 3) you could still run SASS manually.

<comment><USER8> Agreed. Really the only legitimate point is the increased iteration time when working with a preprocessor vs straight CSS. But even that can easily be overcome by using an auto-reloader

<comment><USER9> On a modern computer with SSD drive the iteration time is actually negligible for a not too complex stylesheet; auto-reloading might even be faster than manually refreshing your browser without a build chain.

<comment><USER10> yes, on fast computer with small sass... as the size and number of watched files increases so does the reload time, and while it's still not some huge delay on its own, it does add up when you repeat it hundreds of times a day, and can be a real pain in the ass... to the point that I usually test all my changes live in css first, and then implement the final version in sass later, for easier management.

<comment><USER11> It's a separate issue to CSS processing, but do you not find that tools like live-server or browsersync that hot-reload CSS changes are more efficient than manually refreshing the browser anyway? They update quicker than a full refresh, and if you're working on interactive web apps then they have the significant advantage that any other state you've set up doesn't get discarded while you experiment with styling.

<comment><USER10> I use browsersync all the time, it's a great tool, but IMHO it's still much more hassle then just live editing css in chrome devtools and then having the browser save the changes to local css files directly. No need to reload anything, you just save it and you are free to continue working... of course, sass has many other benefits, it's a way easier to manage, but with devtools pure css workflow is nowadays really fast and streamlined, too.

</comment></comment></comment></comment></comment></comment><comment><USER12> To me this just shows his lack of experience working with a big project where using things like variables and scoping things helps a lot. And what about mixins? To me they are a great tool to fight code duplication, especially once you start dealing with responsiveness for multiple hundred of elements and need to generate similar styling based on dimentions of a screen, I can't imaging maintaining a big site using regular css, it would be a nightmare.

<comment><USER13> > I can't imaging maintaining a big site using regular css

It wasn't that long ago that nobody used [the current big-name] CSS preprocessors. But site admins got along fine, and I certainly didn't hear many complaints.

To each their own, but I don't find maintaining a big site with 'regular' css unimaginable.

<comment><USER14> > But site admins got along fine

Apart from those who generated css dynamically. And those who hated the situation enough to create preprocessors to improve their lives.

"Before X people were ok without X" is a tautology.

<comment><USER15> > _" Before X people were ok without X" is a tautology._

No, it's not.

Sometimes new techniques appear without anybody feeling there was a problem in the first place.

Other times they appear after people struggle and curse their way without them.

"Before X people were ok without X" only refers to the first case, so it's not a tautology applicable to all cases before X.

E.g. people always struggled with webpage layout, and knew they needed a solution X to appear, even before an X emerged.

</comment></comment></comment></comment><comment><USER16> Variables though, I can't see how you can go without them. Being able to change 6 characters and have the entire site theme change for a client is great.

<comment><USER17> I would never allow a design get that far into the process and then allow a client to start testing various colors. That is just asking for trouble.

<comment><USER11> Have you never implemented a design yourself, and then found that when you looked at the results as a whole, it didn't work quite as well as you hoped from the original concept work?

Have you never A/B tested a site and found that varying colours made a difference?

Have you never developed a site with some colour scheme and later found you needed to extend the colour scheme, perhaps to incorporate a new product or service being added to the available range?

Having a colour scheme that is set in stone early on sounds like one of those idealised things that sometimes just doesn't work in the face of reality.

<comment><USER18> I agree!

I'm currently building something that has mild themes for fonts, colors and some margins (and is build on top of a SCSS framework, but that wasn't my choice), without color variables it would be a pain...

</comment></comment></comment></comment><comment><USER19> One of the reasons that I don't use css preprocessors is actually because it promotes very aggressive de-duplication of code. Keeping code duplication to a minimum is a healthy practice for any project, but I find that it is usually a pre-mature optimization for a project where the requirements keep changing a lot (which is especially true for we dev projects).

The disadvantage you get with css preprocessors in this case is that you have lots of tight coupling between a large number of concepts, and you're much more likely to subtly break something unrelated by updating your highly generic code. People have cited 'big' projects as being one of the main reasons to use these preprocessors, but more and more, I find that as projects become larger and larger tight coupling becomes a bigger problem. In this case duplicating code can often the _solution_ , and not the problem (because it reduces coupling).

Of course, after you've shipped the feature you should take time to carefully refactor all the duplication into a common location, but companies often don't give you time for this critical last part.

</comment><comment><USER20> Almost every single comment here is berating this guy for not using SASS, saying he's wrong. Just because he does it a different way doesn't mean it's wrong. Can we please disagree while respecting the guys decision to do what he wants?

There's more than one way to solve a problem, especially in the coding world. There are always "better" ways, but at the end of the day, if plain css works for him and he can solve the problem with it, more power to him. Let's not get the pitchforks out please.

<comment><USER21> His previous blog post berates vendors for using vendor prefixes in CSS. Presumably because this conflicts with his desire not to automate the process by using a tool.

Take an unpopular stance and write a weak blog post in support of it -- while being self-contradictory -- and you can expect people to speak up when it hits HN. I don't see pitchforks. I see people who are smarter and more experienced rolling their eyes while taking some time to share experience late on a Friday night.

<comment><USER20> I was only asking that we respect this guys ability to solve the same problem as the "smarter and more experienced" without the "eye rolling" and condescension. We could instead educate, encourage and inspire people (not necessarily the author, the other HN readers) to new techniques and advocate their strong points while still respectfully disagreeing with an "unpopular stance".

</comment></comment></comment><comment><USER22> This reads as rambling - for example, "I don't feel the "problems" CSS preprocessors intend to solve are serious enough to warrant the cost, i.e. to me the solution is worse than the problem." doesn't really expound on this narrative.

<comment><USER23> It also means he likely doesn't understand the features correctly, which might be because he hasn't encountered the problems they solve yet.

Trying to maintain a gigantic multifaceted application with thousands of lines of just CSS, and half a dozen developers working on concurrent features is a nightmare, source control included.

Breaking apart your application into reusable components represented by single files is an incredible maintainability boost. You can achieve it without SASS but it's features help a lot in achieving it.

The nesting then helps to achieve higher readability for the developers and makes it easy to find what you need to modify.

<comment><USER22> Agreed, just didn't feel the need to bring it up - I feel it's obvious.

</comment></comment></comment><comment><USER24> Although I use Sass, I frankly don't make use of mixins or includes very often. That said, when I actually do need that functionality it's great that I can just write it without having to re-think the solution. The author's point about not leveraging those features too much is definitely something to think about....If I've learned anything in the last 15 years of being a web developer, it's that the best bet is to stick with what the browser provides.

<comment><USER25> I can't imagine what a pain in the ass it would be to deal with a dynamic site (different appearances at different browser sizes) without a preprocessor... Just to be able to nest the media query rules next to the regular rules, instead of inverting them over, and over again.

That doesn't even get into variables and mixins (I use the former much more). Variables in particular help a lot if you have two types of things the same color, and now need to change one of them... wow, that can be a pain in classic CSS without a preprocessor.

I just spent a couple days dealing with a web app that doesn't use any preprocessing for JS or CSS, and man is it hard to deal with... no, I'll stick to babel and at least postcss (if not sass).

</comment></comment><comment><USER26> Is your project small enough that variables don't benefit you? Okay, don't use CSS preprocessors.

<comment><USER27> Actually CSS has variables (even if the syntax is slightly messy) - [https://developer.mozilla.org/en- US/docs/Web/CSS/Using_CSS_v...](https://developer.mozilla.org/en- US/docs/Web/CSS/Using_CSS_variables)

<comment><USER28> No, it doesn't in any sort of browser compatible way.

</comment></comment></comment><comment><USER29> I think you can simply use preprocessors and write vanilla css as well, and using just a few preprocessor's features that could really help you maintaining your code (maybe variable). If you write on sass as you write in css, it will get compiled in the same way. If you find it too slow to compile, maybe you are using an high level compiler. There are native ones like [http://sass-lang.com/libsass](http://sass-lang.com/libsass) and i can't figure out lasting about 1 second to compile.

</comment><comment><USER21> Most of these "complaints" could apply to tools of any form in any discipline. If you've been in tech a while you've heard it all before. Hang around woodworkers and you'll hear people bemoaning progressive use of fasteners, too.

But really... what's the point? He's not particularly insightful in his blog post. Nor does he appear amenable to other viewpoints. "Good job dude, keep micromanaging your CSS. Keeping up to date with the latest -webkit-this-that is an awesome use of your limited time here on Earth. Search and replace when you change shades of blue is _brilliant_. You're a superhero!"

... that's good for two downvotes and nothing else.

So I'll offer this: there's a experience level of engineer where this kind of thinking is common. It's a mix of fatigue and self-micromanagement. Getting to the next level often requires rethinking your assumptions and thinking bigger picture. Don't be this guy.

<comment><USER30> Your argument that you should use a CSS preprocessor because it makes changing a shade of blue easier is a weak one because a) search/replace for such a case IS perfectly viable b) it is likely to occur so rarely that the savings - <USER2> any - will be minimal. There may be other reasons to use a preprocessor, but complicating an architecture for very little benefit might actually be counterproductive.

<comment><USER31> You don't often change the values of variables and you're better at regex than most front end engineers?

<comment><USER30> No, the colours of the sites I look after don't tend to change on a regular basis. And, if they did, a regex wouldn't be required for the search and replace.

<comment><USER21> I'm a designer. There is no "blue". There's the blue in the logo. And then there's the blue saturated a bit more when it's on a gray border. And there's the blue brightened a bit when it's on white. If repeating yourself over and over in CSS makes sense by all means stick to your guns. This practice is verboten in all other aspects of tech engineering and it's only the truly idiotic nature of CSS that has people thinking like this to begin with.

</comment></comment></comment></comment></comment><comment><USER32> "I don't use preprocessors… except… I use PostCSS"

Well, yeah, I prefer PostCSS to others too. Syntax based on future standards is better than syntax invented just for a specific preprocessor, but I don't think the difference is THAT significant.

</comment><comment><USER33> Are you kidding? He even says on his twitter that he is a best practice promoter.

No. You should be using a CSS preprocessor. There are tons of them out there and for good reason. Best practice would be to use SASS.

The only time I could see best practice being "use pure css" is if the project is so small it doesn't matter or you are learning CSS. Even SASS allows you to write CSS and gives you a ton of flexibility in organizing your code. Yes CSS is code.

He even mentions one of the reasons is to avoid having a compilation step. Well lots of things require compilation and generally it is to make our lives easier. The trade off between a broken pipe-line and maintainability via Sass is certainly worth it.

<comment><USER34> > Best practice would be to use SASS.

Best practice would be to use LESS.

<comment><USER31> As some one used less since 2010, it really isn't. Less is like Mercurial, it may be better than git but not enough to make a difference and the network effects of using scss are massive.

</comment></comment></comment><comment><USER35> I love SASS. After years of wroting vanilla CSS, you really get to appreciate some of its features e.g nesting, variables.

The problem is this: for small websites, you don't need to pay a lot of money to get a lot of work done. These are not the greatest developers who use the latest and greatest tools. They write decent vanilla CSS, HTML, JS and that's about it.

For large projects, I would use SASS but for smaller projects that won't grow much greater, for which I have a lot of, CSS is just fine. Gulp, SASS et al complicate the mix and make it harder to get things done and projects turning a profit at a small scale.

</comment><comment><USER36> We have a build that compiles 30 sites of common css into site specific themes. This build runs inside a lesscss plugin for maven that takes 2:24 to build everything. It does them one at a time and seems to throw away commonly compiled bits regularly.

When we dont need new css, we pass a profile disable that wraps the css compile.

This may be an extreme case, but most of it seems avoidable with normal cascades. My front end people want the "convenience" of less, but they dont consider the cost until it hurts their build times.

</comment><comment><USER37> Previous discussion here: [https://news.ycombinator.com/item?id=11409808](https://news.ycombinator.com/item?id=11409808)

</comment><comment><USER38> As long as you don't abuse nesting CSS preprocessors make the world a better place.

</comment><comment><USER39> Fair enough.

I think it really depends on your environment and the scale of your software. CSS preprocessors are trendy and hip right now and often get used with projects that are too small to really need them.

I hacked a little PHP into the stylesheet on my website so I could have some randomized colors.

</comment><comment><USER40> I'm getting tired of these "Why I don't use X" posts. Just use whatever you want and be done with it. Why do you necessarily need to explain your rationale behind it to random people who never questioned you about it?

</comment><comment><USER41> Performance for Sass has not been an issue since libsass. Not once have I been able to switch to the browser faster than my Sass has compiled. Most of the time I even miss the browser-sync reload.

</comment><comment><USER42> "I want my source CSS to be deployable at all times, albeit in un-minified, un-concatenated form."

Add the output css to source control, now you can always deploy that in an emergency.

</comment><comment><USER43> I use CSS processors for name spacing. That's pretty much it.

</comment><comment><USER44> I use LESS to at least define constants easily. It's useful to be able to define your site colors as a few constants to keep things consistent. Theoretically, I could dynamically generate it on the server for the same effect, but that breaks my workflow because I usually write the HTML + CSS first in a prototype page before writing any server-side code.

You can mitigate #4 and #5 by importing less.js during development. I don't know if SASS has something similar.

</comment><comment><USER45> i may be using these tools "incorrectly" but i have a modularized component based structure with components/partials in one directory(e.g sometimes _footers.scss or sometimes _landing.scss based on project) and another with varibles.

However, I compile and write my CSS to disk and serve it. so maybe i am atypical, but i thought that was common. i obviously perfected my workflow over time but i got it setup initially in like 2-3 hours which was a great investment given i use it often and this was 2 years ago. that is why i dont understand this post.

> don't feel problem worth cost

again, it is almost exactly the same as css but you can nest. you can fork a build tool and use it quickly (2-3 hours with a highly optimized setup) and this atrgument doesn't hold up if you use processing as you already have the setup in place, e.g adding 1 module to gulp and just git cloning local if you are that worried about dependency.

> i like control of my css

me too i find nested representation provides better selector targeting, much more readable and reflects the html structure it corresponds to

> deployable

i may be atypical, i just write 1-3 files to disk and they are served as static css

> dont want to wait

i have to wait. it is 2 seconds at most. however, and this is not snarky, that ends up getting annoying. somewhere around under 1 second usually but sometimes you have to reload twice and tricks you into thinking you made s mistake

however, with livereload or nodemon changes propogate quick so the componetization is great for even small projects. doubly if you have to ever collaborate with anyone as it gets annoying dealing with other peoples "best practices" when css is the wild west with a global namespace so collisions and cascading overrides are annoying if nothing else, leaving aside formatting and naming conventions

</comment><comment><USER46> React components with inline css has eliminated the need for preprocessors and stylesheet classes for my team altogether.

</comment><comment><USER47> I can build out CSS at least twice as fast with a preprocessing and it's much easier to update later. why waste your time for some dogmatic belief? It's not like we're programming in 0 and 1s still. CSS is already an abstraction, why fight more abstraction? That's the progress of technology.

</comment><comment><USER48> I started using a preprocessor because I wanted to be able to maintain and compose multiple stylesheets in a complex app with lots of subcomponents with some distinct styling. Once you do that, you've introduced a compiler in your workflow and it may as well be a preprocessor.

</comment><comment><USER49> With the inclusion of CSSnative variables, some functionality may be lost by using preprocessor, but that's a reason to avoid them based on actually knowing them, and this article feelings like it's more subjective attitude than based on experience.

</comment><comment><USER50> I used to be against css preprocessors as well, but nesting is what eventually sold me. It just makes so much sense. My code isn't cluttered with tons of classes, and the css is far more readable.

</comment><comment><USER51> Only one problem I have while using CSS preprocessors. It's not so searchable.

</comment><comment><USER52> Respectful opinion, but as an only part-front-end dev...

> I don't feel the "problems" CSS preprocessors intend to solve are serious > enough to warrant the cost, i.e. to me the solution is worse than the > problem.

I don't think CSS preprocessors _solve_ any problem per se, insomuch that C preprocessors _solve_ any problems - they just help the code without introducing extra syntax to the core language.

> I want absolute control of my CSS, which means I want to work hands on with > it, and see exactly what will be sent to the browser (well, before it's > minified and gzipped, of course). If that means seeing the same declarations > repeated in several rules, or having to see what vendor prefixes look like, > so be it. To me, WET CSS is much more understandable and maintainable than > DRY black box pseudo-CSS.

I don't see how this argument is different from refusal to use any language other than C for complete control. While it _does_ give you complete control, often times it may not even be worthwhile. In fact, SASS constructions are well-defined(enough) that most of time, you can derive exactly how the resultant CSS will look like; of course, some minute optimization may be required but the same argument can be made by pointing out that dlls exist.

> I don't want to learn and depend on a non-standard syntax to wrap my CSS in, > making it require compilation before browsers can understand it. Neither do > I want my colleagues to have to.

Unless your team uses two different method of compilation on one environment(i.e., agreeing on which implementation to use), I doubt there'll be any problem with consistency. If you _do_ use different compilations so that _standardness_ matter, then you have a different problem.

> I want my source CSS to be deployable at all times, albeit in un-minified, > un-concatenated form. If my build process fails, for whatever reason (like > an unpublished npm module), I can deploy the source CSS as an emergency > solution. Performance may perhaps take a hit, but a slightly slower site is > likely better than a site with broken or no CSS until the build process can > be fixed.

This is a non-sequitur on a hypothetical situation on artificial emergency.

> I don't want to have to wait for compilation before seeing the results of my > CSS changes. Processing time may be anything from negligible to frustrating, > obviously, but if it takes longer than the time it takes for me to switch > from my code editor to my browser and reload the page (≈1s) it's too slow.

filesystem watch generally handles the auto-compilation, and am I the only one who edits css _on-browser_ first before editing files on CSS sheet? If the only way to edit styles on web page is editing the source and reload, this method will definitely cause much more frustration on dynamically generated applications.

I can sort of see where this person is coming from, but I would say the benefit outweighs the cost here. Again, personal preference, but I would rather have my team employ preprocessor just for variables and palette from designs.

</comment><comment><USER12> Looking at his other articles on his blog I stumbled upon this one: [http://www.456bereastreet.com/archive/201304/responsive_drop...](http://www.456bereastreet.com/archive/201304/responsive_drop_shadows/)

He recommends using images in order to create a shadow...and that was in the middle of 2013, when "box-shadow" css attribute was supported by all major browsers with some prefixes...and the funniest part is that he is using shadow image as an :after pseudo-element which has the same browser support as the "box-shadow", this tells a lot about his CSS skills.

<comment><USER53> Perhaps you should check your own CSS skills before trying to find further information on his blog to simply use to trash him? This wasn't even constructive it was just a rush to find _something_ to say "ah ha!".

IE8 supports :after[1], IE8 does _not_ support box-shadow[2]. Furthermore he even explains, in his first paragraph, that what he is showing allows for a more _complex_ design look over 'box-shadow' which, even if what you originally said was true about browser compatibility, it _still_ explains his reasoning and says _absolute nothing_ about his CSS skills.

[1] [http://caniuse.com/#search=%3Aafter](http://caniuse.com/#search=%3Aafter)

[2] [http://caniuse.com/#search=box-shadow](http://caniuse.com/#search=box- shadow)

<comment><USER12> from the article: "I then gave the box element a padding-bottom in percent, calculated by dividing the image's intrinsic height by its width, in this case 37 by 992 pixels"

What the hell is that? if somebody recommends me doing that he obviously is not that good with CSS.

Also how is support for IE8 is even relevant? It's a 7 year old browser.

<comment><USER54> > Also how is support for IE8 is even relevant?

Ten employee business, 5% of clients today on IE8. We have fewer users on Firefox, so we should do support for that too... And we might as well stop supporting our Android users too.

Generally we drop support when user stats drop below 1%. Even that can cause a lot of trouble for our client businesses (we don't want to be hated for making them change, regardless of how impatient we are for them to do so, or how insecure they are for not doing so).

<comment><USER12> If a customer is still using IE8 I am positive that he will be OK with not seeing a box shadow on an element, and making 95% of other clients suffer and download images for generating box shadow is just plain stupid for me. I would either ditch those 5% of clients and focus on better features than spending lots of time on restraining cool functionality in order to satisfy a 5% of users on IE8

<comment><USER53> > making 95% of other clients suffer and download images for generating box > shadow is just plain stupid for me.

The images are likely a few hundred bytes if you do it right. Regardless this is an old article you dug up just to attack the guy; OBVIOUSLY it's far less relevant today than it was when it was originally written.</comment></comment></comment></comment></comment></comment>


How I Sped Up My Site 68.35% with One Line of Code - <AUTHOR> http://ipullrank.com/how-i-sped-up-my-site-68-percent-with-one-line-of-code/ <comment><USER2> So how long until prerender gets abused to make our clients do way more work than necessary?</comment>


Live 24 hours online conference about LoRaWAN - <AUTHOR> https://www.youtube.com/watch?v=7XwF8VLvSvM <comment><USER2> Inventor of LoRa technology is presenting in half an hour!

</comment><comment><USER3> 24 hours of content, I need to ask for the day off!!

</comment><comment><USER4> nice</comment>


The 2014 Mac Mini reviewed - <AUTHOR> http://arstechnica.com/apple/2014/11/not-the-upgrade-we-were-hoping-for-the-2014-mac-mini-reviewed/ <comment><USER3> Ugh. This is the trend that will finally push me off Apple desktop/laptop hardware:

"you'll finally see that the new Mac Mini's RAM is soldered directly to the motherboard. It's no longer user-upgradeable, so make sure you order all the RAM you need when you buy the computer in the first place."

<comment><USER4> I wonder why they did this? In the case of the macbooks and iMacs at least, it can be somewhat justified as a space saving measure. However the new mini is the same size as the old one and it's already quite tiny.

<comment><USER5> One tangible reason is support costs. A new Mac mini is never going to the Genius Bar because of bad third party memory, or badly seated memory, or a static shock administered to the mother board while the memory was being changed.

Even if those are quite rare, support incidents can be expensive, so it could be a dollar or two average per mini being saved.

<comment><USER6> I remember when CMOS was new and static really did damage just about every part you handled if you weren't careful. Little conductive wrist band connected to steel desk, carbon coated conductive foam to work on and so on. But for the life of me I can't remember when a part failed due to static in the last decade or even longer. If anything broke it was either a cable or a soldered connection to a board.

Sure, I've had RAM break, but that was _factory_ installed RAM that was several years old. This is definitely anecdata but it would be interesting to know how much damage static really does these days. If you're going out of your way to pet your cat prior to installing your RAM chips on a glass floor or something like that then you're probably asking for it. But regular precautions (place RAM container _on_ the case before opening package, hold the case while inserting the RAM) seem to be more than enough. On chip ESD protection has come a long way since the 80's.

[http://www.amazon.com/On-Chip-Protection-Integrated- Circuits...](http://www.amazon.com/On-Chip-Protection-Integrated-Circuits- International/dp/0792376471)

</comment></comment></comment></comment><comment><USER7> I have been using a 2012 mini as a home server, but recently when I needed to upgrade I decided to get a Dell T20. Cheaper, more and more powerful cores, and lots of internal expansion possibilities. Of course, the trade off is that it's considerably bigger, but it's just sitting in a closet at home so it's not a big deal. Oh, and at idle it only uses 20 watts, about the same as the mini.

</comment><comment><USER8> I posted this a few days ago:

[https://twitter.com/JeremyCMorgan/status/529727399353937922](https://twitter.com/JeremyCMorgan/status/529727399353937922)

I was curious because of the differences in the U vs M processor so I went into Best Buy and ran Geekbench on one.

I know CPU isn't everything... but what exactly would be a reason for putting a power saving CPU in something that's plugged into the wall? My current Mini already uses far less power than any of my old stand up PCs of the past.

I'm kind of puzzled what the selling point to the Mini is now. At first it was an affordable Mac for those who don't have the money (or want to spend the money) for a pro, but at this point it seems to just be an underpowered box you can't upgrade for roughly the same price as a macbook air or better powered PC.

<comment><USER9> Power=heat. If you want a tiny box without a lot of fan noise you need to watch your power.

I think the point of the Mini is "good enough for many people". And great for them. No sense buying RAM sockets you will never use, solder it down. That's a cheaper and more reliable connection.

Most people who purchase a mini never upgrade RAM or persistent storage. Remember that if you are posting on HN, you are an anomaly and live surrounded by similar anomalies so you may not realize it.

<comment><USER10> _Remember that if you are posting on HN, you are an anomaly and live surrounded by similar anomalies so you may not realize it._

Most non-technical Mac users that I know have MacBooks (having worked in a linguistics faculty, I knew many). The only Mac Mini users that I know are actually techies.

Edit: of course, in the end it does not really matter. The Mac Mini is probably a tiny slice of the total number of Macs sold. For other models people (including me) already accept paying much extra for upgrades.

<comment><USER9> It occurs that I may have an observer bias, since I only see someone's mini if I am in their office or house, but can see their laptop many places.

I was going to use Amazon's _Best Sellers_ to try to ferret out how few Mac Minis really get sold compared to iMacs and laptops. At least at this moment, Mac Minis are the best selling Mac. No doubt from fence sitters waiting for an announcement, but interesting none the less.

#12 Entry level Mini

#21 Middle iMac

#30 Middle Mini

#34 Low end iMac

#42 Whiz-bang 5k iMac

#50 2012 Mac Mini (quad core coveters)

#80 High end Mini

#87 Ancient, used 17" iMac. Really? sort of in the weeds here.

#100 2012 Mini, but volume must be near zero to be under that iMac.

</comment></comment></comment></comment><comment><USER11> Its actually more expensive when you try to get near what the 2012 model had. They really messed this one up. 2 cores not 4, soldered RAM, and no 2 hard drives.

I wish Apple would throw people who cannot buy the Mac Pro a bone, but that's not the way of a consumer electronics company.

</comment><comment><USER12> I predict these will be pretty short lived; there will be a Late-2015 Mac Mini with 4K 60Hz which hopefully also fixes the quad core problem (lack of).

Sticking with my 2011 and 2012; I might upgrade the 2011 to a 2012 if I can get a cheap refurb.

</comment><comment><USER13> We'd been waiting to replace our '12 minis with new ones in the office, but have instead just gone for MBP retinas. Can't see any reason to go with the minis now they're not upgradeable at all, other than price.

<comment><USER14> Why does it need to be replaced? '12 mini would still be going strong.

</comment></comment><comment><USER15> I made a quick video with the same conclusion: stay on 2012 and wait until a worthy upgrade comes along. (Well, unless you want PCIe SSD I/O bandwith -- that's much faster. But multicore is sooo much slower that it's not a clear win.)

[https://www.youtube.com/watch?v=QmmkD2rgNgA](https://www.youtube.com/watch?v=QmmkD2rgNgA) No need to watch the video, all the info is in the description.

</comment><comment><USER16> In theory it's off-putting, but in practice I'm not really bothered by the changes. If I were to buy one, it would only be as a home server for iTunes Library hosting (to AppleTV) and as a backup destination for CrashPlan. My current server is an old Dell desktop that draws a lot of power and it's pretty noisy. Even the base configuration of the mini is plenty for what I would want to do with it.

</comment><comment><USER17> It would appear they are just offering what Intel has available. I'm guess the Intel I5-4260U as it's 1.4GHz w/ Intel 5000 Graphics. It doesn't look like Intel even offers a mobile version of i5 with 4 cores and I couldn't find a mobile i7 with 4 cores and intel 5000+ graphics. This is one area A10 APUs that AMD really has Intel beat.

<comment><USER18> Intel does offer quad-core mobile chips with Intel 5000+ graphics. Apple's even shipping them in the 15" retina MacBook Pro. Here's the mid-tier chip:

[http://ark.intel.com/products/83504/Intel-Core-i7-4870HQ- Pro...](http://ark.intel.com/products/83504/Intel-Core-i7-4870HQ- Processor-6M-Cache-up-to-3_70-GHz)

The issue with using these in the Mac mini, as mentioned in the article, is that they require a different socket than the dual-core i5 chips. If Apple wanted to offer both dual and quad-core chips in the Mac mini, they'd need to design and ship two different boards.

It might have been more costly to do so, but I think that Apple's doing their customers a great disservice by not offering something between a dual-core i5 with soldered RAM and the $3K Mac Pro.

<comment><USER17> ah Thank you for pointing that out. I think the rMBP is actually a great middle of the road option. It supports multiple monitors with 2xthunderbolt,1xhdmi. I've seen lots of companies opting for these over mac minis and just having employees dock them in clamshell mode.

</comment></comment></comment><comment><USER19> I got a Zotac Zbox a while ago instead of a mini and was wondering if anyone else has seen any nifty things in the micro ATX world?

<comment><USER20> My main desktop machine is an Asus Chromebox with an upgraded SSD and Linux installed. Had a hex-core 3.8GHz tower sitting right beside it, but I found I never booted it.

I spend most of my life in terminal windows, but it runs FireFox, the Gimp, and older games like HL2 just fine. Fan almost never goes on.

<comment><USER21> I'm quite interested in that. What model/cpu/ram do you have? And when the fan goes on how loud is it?

<comment><USER20> It's a M004U (AKA CN60). I should also have mentioned that I bumped the RAM to 6G (though 4 would have been fine). CPU is a Celeron 2955U, 1.8GHz dual core.

Fan's moderately loud. It seems to only come on when the GPU is stressed, rather than the CPU (playing 3D games, essentially). Doesn't come on when I'm playing movies or compiling code.

I run Arch with XFCE as my desktop, which I admit isn't very demanding - <USER2> it's zippy. Can't say what it'd be like under Gnome/KDE, but if I had to bet I'd say it'd be fine.

Installing Linux isn't for the faint of heart, but there's some good guides and it doesn't take long.

</comment></comment></comment></comment><comment><USER22> The $500 Mini is a dishonest lie by Apple.

Look at what happens when you give the 1.4 Ghz model 8 GB Ram and a fusion drive, it costs $850.

If you take the 2.6 Ghz model, you end up with $900 for that configuration. A 50$ price difference for a 1.4 vs 2.6 Ghz processor.

The Mac Mini performance and pricing is just maddening.

<comment><USER23> They're trying to kill it.

<comment><USER24> Why try to kill it? Why not just do it by not offering it anymore?

<comment><USER25> Apple isn't one monolithic creature. I'm assuming that some are trying to kill it (by making it underpowered with low sales) because they can't kill it politically (it's one of Steve's babies.)

It's kinda like the old iPod. They kept making it _long_ after nobody bought one, because it was the iconic turn-around device for Apple. Cook admitted they had to stop making it because they couldn't find parts anymore.

</comment></comment></comment></comment><comment><USER26> Intel NUCs are similar in size to Mac Mini - I've been using for small linux servers and dev boxes. NUCs can handle 16GB ram, quad-core, SSD, GB ethernet.

Small and quiet - a great little device.

<comment><USER27> What are good retail NUCs?</comment></comment>


Google offers $500 reward for finding out security related Chromium bugs. - <AUTHOR> http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html#

<comment><USER2> Great initiative. Note that for 3l33t (severe) bugs found they will pay $1337 instead.</comment>


FUCK Token - <AUTHOR> http://fucktoken.io/ <comment><USER2> lmao made for people to give a fuck. This is awesome. XD</comment>


Show HN: Remove duplicates from a list online - <AUTHOR> http://www.remove-duplicates.xyz/ <comment><USER2> Curious if there is a source code repository.

<comment><AUTHOR> I haven't made it public. I didn't think anyone would care about the code. Let me know if you want me to publish it.

Technically, it's a static website made with Middleman and a tiny bit of Javascript. I am using Pure CSS as a base for styles.</comment></comment>


Living cells are very fast and crowded places (2012) - <AUTHOR> http://www.righto.com/2011/07/cells-are-very-fast-and-crowded-places.html <comment><USER2> I highly recommend the book "The Machinery of Life" by David S. Goodsell. It isn't too long, the text is interesting with out getting too bogged down in the details (there simply would be too much to cover in detail), but the highlight is he a professor of molecular biology, he is an excellent illustrator, and the book is packed with detailed illustrations that alone make the book worth it. $18 on amazon. (get the 2nd edition, not the 1st edition)

Just do a google search for images on the book title and author name to see what is inside.

<comment><USER3> Sounds great! Along these lines, I've really enjoyed some of the iBiology[0] videos, especially the ones about molecular machinery. It's the 3blue1brown[1] of molecular biology.

0\. [https://www.youtube.com/user/ibioseminars](https://www.youtube.com/user/ibioseminars)

1\. [https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw](https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw)

</comment></comment><comment><USER4> I wish I understood where all this stuff came from. When we talk about evolution we talk about random gene mutations and natural selection, but it doesn't seem like the machinery of the cell itself is described by DNA. How do cells themselves and all their internal machinery evolve?

If all you had was a genome, could you really use it to engineer the cell required for it to go inside of?

<comment><USER5> If all you had was unix kernel machine code, could you really use it to engineer the hardware required for it to go inside of?

<comment><USER6> This is a bad analogy - the instructions for making everything in the cell is in the dna, so you also have the blueprints for the hardware fabrication plant.

<comment><USER7> No, it's a pretty reasonable analogy. For the original point, if all we had was machine code, and that code had a complete description of the machine which could run it and how to create it, it would still be useless without a machine to process it. The code on its own would not be sufficient to create the machine.

You can't make use of DNA without all the complex machinery required to transcribe it, translate RNA and replicate it. There's a chicken and egg problem. The DNA does indeed encode the instructions to make and assemble all the rRNA, tRNA and protein sequences to do this, but you have to already have the machinery in place to do so. Kind of like compiling a compiler. You need an initial manual bootstrap, which in the case of life as we know it, took place many millions of years in the past. Just as the code for a compiler is just so much meaningless ones and zeroes without a working compiler to process it, so is DNA in the absence of the translation machinery. Without any context for how to process it, it's just a meaningless jumble of bases.

One thing to think about. If we discovered intact dinosaur remains with non- degraded DNA, could we resurrect it? We don't have the machinery since it was lost with the death of the organism. But we could potentially bootstrap it by placing it in the cell of a related species, e.g. a reptile. But if it was a completely different form of life, we wouldn't even know where to begin.

<comment><USER6> >> if all we had was machine code, and that code had a complete description of the machine which could run it and how to create it

That's a reasonable analogy but it's not what the original poster said.

</comment></comment></comment></comment></comment><comment><USER8> The information processing capability of cells, and the fact that single- celled creatures have behaviour, makes it hard for me to believe that neurons (not just in humans, in all animals with neurons) _don 't_ use any of this information processing capability.

I understand researchers have claimed to replicate the brains of some very simple animals (having something like 306 neurons)... but have they replicated the behaviour, i.e. for the same initial and ongoing inputs, you get the same outputs as the modeled brain? That should show the accuracy of the neuron model.

<comment><USER9> They've tried, but there's definitely a lot more work to do. If you're interested check out the Open Worm project

[http://docs.openworm.org/en/latest/faq/](http://docs.openworm.org/en/latest/faq/)

</comment></comment><comment><USER10> > cells are extremely crowded and busy places

Cells are extremely crowded and busy... _and random and violent_ places.

Molecular biology dances in a nano moshpit from hell.

 _The Inner Life of a Cell_ is badly misleading. It reinforces many educationally toxic misconceptions. Yes, the graphics technology was limiting. But the video doesn't attempt to mitigate the negative impact. For instance, adding a couple of frames of Goodsell's crowded proteins, fading to sparseness, could have reduced its reinforcement of the "big empty cell" misconception.

And it doesn't just hide almost everything (crowded), or slow everything way down (busy), or show completely aphysical rendezvous and docking (random), but it also strings together carefully selected snapshots to tell a misleadingly peaceful narrative (violent).

That kinesin walking along, towing a vesicle? Its "feet" are actually madly flapping around. It is randomly "stepping" back and forth - only its _net_ motion is biased. And between one net step and the next, that big vesicle has been slammed around to every position within reach of that tether. It's a random walk on a leash. Reality isn't a donkey quietly towing a slowly-moving barge. It's a balloon flapping madly in a hurricane, tethered to an intoxicated panicked mouse clinging to a rope.

Biology rides a ragged energetic edge, between things being too strong, too expensive to dis/assemble, and being smashed to pieces too quickly.

More generally, the video illustrates a pervasive problem with science education media. Even when done "well", some aspects are done with great skill and care, while other aspects are silently left utterly bogus. Pity the students, who lack the knowledge to sort out _which is which_. So rich ecologies of misconceptions are established. And are intractably expensive to displace. It's so easy to create content that leaves students worse off than if they had seen nothing at all. So that's, in general, what we create.

The violence of nanoscale is a critical, defining characteristic. That so many biology undergrads are unclear on it, let alone high-school and primary students, shows just how very far we have to go before teaching deep understanding, transferable knowledge, and cross-cutting principles, finally becomes a reality. Or more upbeat, how breathtakingly awesome science education might eventually become.

(FWIW, the top section of my very crufty [http://www.clarifyscience.info/part/Atoms](http://www.clarifyscience.info/part/Atoms) might help some with getting a handle on at least the size aspect of small things.)

<comment><USER11> Thank you for this writeup that peels away a layer of simplification and more vividly and accurately explains what is going on. you have a way with words. The intoxicated panicked mouse will stay with me forever.

That being said, I don't agree that it is a pervasive problem that simplification and abstraction is used in teaching. New concepts have to be introduced piecemeal. If a new topic was explained to an audience of neophytes in all its gory details, the effectiveness of the knowledge transfer would be low. Some may grasp the complicated details and form a valid mental model. However, many will be put off, as it is too much stuff at once.

Teaching is about introducing a simpler model first. Such a model is a rough abstraction with tons of simplifications and inaccuracies. Once understood by the student, it is about introducing a more intricate and realistic model, while demolishing parts of the simpler one that no longer fit. Once this more intricate model is internalized, another even more detailed one can be taught. This goes on until you get to the limits of understanding of a certain system or process. At that point, the student has the option of becoming a researcher and forging new models that have not been created before.

You can not dump the most detailed and intricate model on new students. At the same time, a good teacher is cognizant of the fact when their students have a solid enough grasp of a given model to start introducing the more intricate one, while dismantling the old one. It's a tough balancing act.

<comment><USER12> Yes, our understanding gets more refined the more we learn. It remains messy, error-prone and incomplete. So the solution can never be to learn things 'well' or get things right first time or produce perfect teachers/videos or something like that. The solution is to go on correcting misconceptions where we are interested. Ken Shirriff's blog, mncharity's website, comments here and so on simply _are_ part of the ongoing spontaneous correction process. Like the contents of a cell, they may look crazy and disorganised but they get the job done.

<comment><USER13> Hi erasmuse, the Fallible Ideas mailing list ([http://fallibleideas.com/discussion](http://fallibleideas.com/discussion)) would be a more fruitful place to discuss your ideas. There, openness to new ideas is valued, as is being willing to discuss disagreements persistently until resolution.

[http://fallibleideas.com/paths-forward](http://fallibleideas.com/paths- forward)

<comment><USER12> I doubt it. New ideas develop slowly and can't be communicated or explained until they are ready. If you look at creative intellectuals they work alone or, rarely, in pairs. Discussion to the point of resolution would be more like politics or opinion-leading; perhaps necessary for defence or for sorting out existing ideas but otherwise harmful to progress.

<comment><USER13> Work has multiple parts. Some work is done alone, some in pairs, and some in a public group. The public group part has value and importance: for example, getting more variety of criticism and other feedback such as what people don't understand. Work done in a public group also helps others learn, so that's good.

If, hypothetically, you should join the group, in what way could you find that out? What would change your mind?

Example of Fallible Ideas thinking: [http://fallibleideas.com/taking-children- seriously](http://fallibleideas.com/taking-children-seriously)

<comment><USER12> _> What would change your mind?_

Something like historical examples of fundamental breakthroughs in science or great works of art produced by committee.

Criticism is for stuff one _doesn 't_ like, which is why it belongs firmly in the public realm of news, politics, etc. A group isn't public. When it comes to your private work, ignore criticism and trust your intuition. Ideas need room to grow just like children do.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I spoke to a colleague who had done some work in his PhD in the physical chemistry of cells. Concepts like 'liquid' do not translate well at the intra- cellular level. 'holes' or 'channels' in a membrane, again are mostly about metaphors rather than mechanistic statements of completeness. he said for some things, an Escher infinite-space filling grid was as good a metaphor, for the cellular structure that the various organelles negotiate. (this btw, is asinine, and would deserve a "physical chemist here: this is bullshit" response)

<comment><USER15> To clarify: your colleague's comment is asinine?

<comment><USER14> Ah grammar, where would we be without you.

</comment></comment></comment><comment><USER16> Although there is truth in the post, this is not entirely correct. Many chemical and biological processes take place in a much slower timescale than hundreds of thousands per second, many miles per hour etc.

These processes include DNA synthesis/cell division, transcription, the transmission of electricity / ions between neurons, and many other basic processes.

Also, Many proteins don't simply float every around the cell at these massive speeds - they form stable, localized protein complexes that keep on doing what they're doing at the same location for quite a while. That's why we can image them and make real-time movies at human scales of perception (seconds, minutes etc.).

Even more so for more complex processes - this is also why cellular motion takes quite a while - go on youtube and watch dictyostelium cells move towards folic acid. It takes quite a while, many hours in fact despite the presence of a very clear folic acid gradient as the signal.

<comment><USER17> Also, speeds like "100 times per second" should be scaled down with the size scaling, if you want a feel for mechanics. Times Square is about 1km long, and a eukaryotic cell around 10 microns, so scale by 100 million. (A pretty typical protein, 5nm across, becomes 0.5 meters across in Times Square.) From this perspective even the rapid purposeful actions the article talks about go extremely slowly: 100Hz becomes a million seconds per action -- a couple weeks. The biomolecules do whip around at random very fast -- but net progress happens only after a _lot_ of wriggling.

<comment><USER5> > Also, speeds like "100 times per second" should be scaled down with the size > scaling, if you want a feel for mechanics.

I'm a little confused, are you saying that the _real_ speeds and rates in the article/this thread are all too fast by a factor of 100 million, or are you saying that its useful to perform this scaling mentally when imagining these systems to get a better intuition of their mechanics...?

<comment><USER17> The latter. Maybe I should reread the post, but it invites you to visualize a cell as Times Square -- scaling the sizes -- and then the unscaled speeds give the wrong impression within that visualization. (Mechanical properties like stiffness don't vary when you scale space and time together.) Outside of it, of course the absolute speeds are what you want to know.

<comment><USER5> Thanks for the clarification, I see what you're getting at.

</comment></comment></comment></comment></comment><comment><USER18> I found Goodsell's images of the crowded intracellular environment in E. coli, useful visualisations in developing a model of a living cellular process, namely, transcription control. Transcription is the first step in gene expression: in E. coli, RNA polymerase transcribes a complementary copy of a gene, namely, messenger RNA, for further processing to protein. The transcription process is controlled by proteins that either compete with RNA polymerase for the start site of transcription (turn off the gene) or bind adjacently and promote transcription (turn on the gene). The difficulty I had in constructing a mathematical model of transcription control was that I wanted to include nonspecific binding, where RNA polymerase binds with low affinity to random stretches of DNA. While such binding occurs with low affinity, the sheer length of the DNA meant that a significant proportion of the RNA polymerase was bound in that form. Fortunately, I became aware of the work of people like Allen Minton (NIH) and Tom Record (U Madison-Wisconsin) who studied molecular crowding. To borrow a sentence from Wikipedia, "[H]igh concentrations of macromolecules reduce the volume of solvent available for other molecules in the solution, which has the result of increasing their effective concentrations." [https://en.wikipedia.org/wiki/Macromolecular_crowding](https://en.wikipedia.org/wiki/Macromolecular_crowding) I found (I hope correctly) that Tom Record's quantification of crowding, as affecting a 100-fold increase in concentration, "exactly" compensated for the reduction due to nonspecific binding. [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5425810/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5425810/)

</comment><comment><USER19> I am suddenly very uncomfortable, imagining myself as a roiling blob of goo.

<comment><USER20> If it helps, consider that you are the descendant of the original "grey goo" which since pervaded the surface of an entire planet. The inheritor of a billion years of techniques in construction, alliance, deception, and warfare. A uniquely coordinated swarm of assimilating nanotechnology, poised to leap into the cosmos.

... No pressure.

<comment><USER21> Or you can sit here and wait to become a star again.

</comment></comment></comment><comment><USER22> This article mentions two things as if they are unrelated. That the cellular environment is crowded is exactly why you need transport proteins and vesicles. All the really fast proteins are mostly going nowhere, they're just wobbling on the spot bumping into everything crammed next to them. Sandwiched most of the time between membranes they cant diffuse through freely. Its like angry jelly not hot soup.

</comment><comment><USER23> "As a result of all this random motion, a typical enzyme can collide with something to react with 500,000 times every second. Watching the video, you might wonder how the different pieces just happen to move to the right place. In reality, they are covering so much ground in the cell so fast that they will be in the "right place" very frequently just by chance."

That's the problem with those visualizations - they aim to give one an intuition of what's happening, but in fact they mislead. I wonder how it's possible to give an intuition of the reality, when in addition to the crazy statistical noisyness of the scene, those molecules are also in quantum superpositions.

</comment><comment><USER24> God is a using 4 dimensional Autocad, unaware that his gears and cogs have created life. that's my guess.

</comment><comment><USER25> Interesting.... Its very difficult to think about works of cells... if god is there... he is so great of creating lifes...

<comment><USER22> If god was so great (or at least smarter than humans) most of it would work a lot better than it does!

<comment><USER26> Care to explain? What could be improved?

<comment> D-Coder Knees. What half-competent engineer would hold a weight-bearing joint together with soft tissues?

Teeth. Replacing these with a new set every 10 or 20 years would be pretty nice.</comment></comment></comment></comment>


The Stanford Facebook Class (2007) - <AUTHOR> http://www.stanford.edu/group/captology/cgi-bin/facebook/

<comment><USER2> As a Computer Science student in a state University, this is very cool. I would love to take a class like this.

</comment><comment><USER3> This is 4 years old.</comment>


Show HN: Stressed and busy? Reduces stress while using your laptop - <AUTHOR> https://www.lumiate.co <comment><AUTHOR> Hi there,

This app is perfect for the remote work environment... A patented approach that pulses display gamma to reduce stress and increase focus without interrupting what you are doing. The idea is that when we start getting mentally taxed under a deadline, "taking a moment" is difficult. This product helps you out without requiring you to stop what you are doing.

<comment><USER2> This sounds like a great way to reduce my Starcraft 2 ladder anxiety! I was thinking of giving up my 2 pylon before gateway build, but maybe with this I can push though.

<comment><AUTHOR> Nice, I'm looking at getting a PC that I can game on for similar reasons. I wish I knew the terminology that you were referring to, but I hope you give it a try and reach out with any questions!</comment></comment></comment>


Free Vector Conversion API - <AUTHOR> https://www.vector.express/api-frontend/ <comment><AUTHOR> I made this for my company a while ago, but I thought I'd make a free version of the API. I'm thinking of a v2 though that should be a bit more developer friendly.</comment>


Want To Be More Productive? Work Slower - <AUTHOR> http://thinkspace.com/want-to-be-more-productive-work-slower/

<comment><USER2> I used to think it was great to take on a ton of things at the same time. Now, I just look to simplify and actually make progress. I have a strip of black electrical tape on the door and I focus on just a couple things each day that are above the line and move everything else below the line that isn't helping me move the business forward.

</comment><comment><USER3> Awesome blog post, Kelly!</comment>


Who Pays for Cheap Language Instruction? The Dangers Behind Duolingo - <AUTHOR> https://bostonreview.net/class-inequality/yuliya-komska-alberto-bruzos-moro-roberto-rey-agudo-who-pay-cheap-language-classes <comment><USER2> >The company she works for, 51Talk, charges learners an average of 45 yuan ($6.36) per 25-minute session. Yet teachers receive on average only 130 pesos ($2.53) per hour. English, a legacy of U.S. imperialism in the country, may have made the Philippines one of Asia's largest providers of proficient speakers, but it is certainly not showering online language teachers with riches.

People work jobs that make them money, they work jobs that give them the most money. If she didn't want to do that job, she would choose another better paying one.

>"Learners" on Duolingo are actually just performing the free labor—or even paying for the privilege—of helping the company improve its proprietary algorithms.

Learners don't benefit at all from learning a language, they're just cogs in a wheel, in fact learning languages hurts them and wastes useful calories that could be better used like thinking about what to wear or the regretful thing they forgot but remember now.

I fail to see the danger of combining translations and language learning together.</comment>


Wanting to leave IT - <AUTHOR> I'm 50 this year, been in IT for 20 years and I wanted to get ideas from those willing to share them on switching gears and leaving IT for something else.
I'll be frank: I'm burned out after 20 years of being in IT. IT, at least for me, due to the push to the cloud and other factors, has been reduced to disaster management. I live in a place with precious few actual IT jobs. I'd like to use computers as a tool, not the focus of my life.
My degree is in CS and before I was in IT, I was a barber--something I have no wish to return to, as standing all day created health issues for me, hence my entry into IT.
Any ideas? <comment><USER2> If you have a degree in CS, you could go into software development. Or even teaching. I hear that schools are desperate for CS teachers.

Have you considered retirement? 20 years of IT is enough for you to retire on.

Do you have any careers you want to get into?</comment>


Ask HN: Running list of startups/companies that iOS5 went after - <AUTHOR>

By my count so far:<p>Instapaper, Dropbox, Remember the Milk, WhatsApp, Facebook, RIM, Sparrow, ATT, Verizon <comment><USER2> Not that I want them to go, but Square and Oyster should be next. <http://en.wikipedia.org/wiki/Square_(payment_service)> <http://en.wikipedia.org/wiki/Oyster_card>

</comment><comment><USER3> Yeah Dropbox will need to step up a bit more. maybe this will mean we get more than 100gb of storage as an option without have to pay $750 a year for their Teams product!

</comment><comment><USER4> TaskAve (<http://taskave.com/>)

</comment><comment><USER5> Things from CulturedCode

</comment><comment><USER6> not a startup obviously, but all of the Google apps with iCloud

<comment><AUTHOR> Perhaps I should change the wording to startup/companies Facebook, ATT, Verizon aren't either. Quite a nod to Twitter.

</comment></comment><comment><AUTHOR> OpenFeint</comment>