Google Bans Developer for Life - <AUTHOR> https://medium.com/medium-long/banned-for-life-c62f2404f66

<comment><USER2> You get an app banned and it doesn't occur to you that maybe you should pull the other apps that couple violate the same nebulous terms? The "I grew up in the 70s/80s and it was cool to defy authority if you didn't agree" argument is a canard. If you claim to be a professional developer then act like one. Getting in a pissing contest with Google will not end well.

Expecting Google to act like a sane company for one developer in a garage is naive.

</comment><comment><USER3> Guy makes a bunch of spammy apps that clearly rip off third party trademarks, gets banned from Google Play. While I think this could have been handled better from Google's side (such as a way to let him post a new app in the future, with appropriate review, if he agreed to knock it off), I'm not sure what else you'd expect. He even acknowledges ripping off the app icons.

<comment><AUTHOR> I agree that he did violate one of their terms of service, and, like you, I believe it is unfair and too extreme to ban him from ever submitting an app to the Google Play store again.

The author links to a few other people who have also been banned. It's amazing that Google does not provide some way for developers to get reinstated in the Google Play store. Google basically owns the Android app market space and a ban for life is too severe.

<comment><USER4> It is possible to be reinstated, but very difficult - I signed up for a Play Developer account a year ago, and didn't end up using it at all. A few months later, I got an email saying my Play Developer and Wallet accounts were banned. I emailed their appeals system once and got an autoresponse saying it wouldn't be reviewed. I emailed again and got a personal response saying they couldn't tell me why they banned it for "security reasons". I pushed them, and they finally told me it was part of some sort of auto-ban on a Play Developer account that had also banned all other "associated" accounts. I only have one account. I asked them to investigate further, and got told it wouldn't be reviewed. I finally managed to contact someone at Google Support who helped put me through to someone on the Google Play team, who finally confirmed it was a bug in their system designed to automatically find associated accounts when banning a particular account. Someone else had been banned, and I was caught up in the sweep.

I finally got my Play Developer and Wallet accounts reinstated, and I promptly shut down my Play Developer account so that I wouldn't risk having my Wallet account accidentally banned again due to someone else's actions. Now I just develop for iOS.

</comment></comment></comment><comment><USER5> 1\. The author chose to blatantly ignore clear signs of a problem.

2\. Then proceeds to make all sorts of insane and stupid reasoning to defend what is obviously his problem for ignoring the issues.

3\. Even after the lifetime ban came in, he chooses to ignore the problem was with him and what he chose to do, and instead still holds his innocence and expects someone on Google's end will realize their mistake when in fact it was his.

I believe a lifetime is a bit too harsh. But I also believe that when someone makes a mistake and doesn't bother to realize the problem themselves and instead continue to cry innocence like a dunce, they probably should remain banned until they get a clue.

Also the argument that others got away with it is NEVER a good argument for why you should be allowed to do something (not saying thats what he said) or that it should be okay for you in any way (something he did say).

</comment><comment><USER6> While I think this guy was more than a little ignorant and probably should have been more careful, Google's policy here is just ridiculous. Banning someone from literally everything and offering no real process for contacting the company is more than over the top.

I lost my Google AdSense account a while back because I forgot to update my address when I graduated from college. There's no way to get it back, and if you create a new one it immediately recognizes you and tells you to use the old one. There's no customer support you can talk to.

If Google wants to stick by their whole "Don't be evil" mantra, they really need to look into their customer support policies in general.

</comment><comment><USER7> Like others here I'm a little short on sympathy for the author specifically, if Google bans one app, I think I'd be upset about it enough to not just let it go under the assumption I was innocent - obviously someone or something at Google disagreed.

However I do think that banning anyone "for life" over three apps is a bit much. Ban the developer account, fine, but Google has gone to such great lengths to entrench people in their own ecosystem that a more widespread ban (like Wallet) can have repercussions far more punishing than the crime.</comment>


SolidRun ClearFog: A 16-Core ARM ITX Workstation Board Aiming for $500~750 USD - <AUTHOR> https://www.phoronix.com/scan.php?page=news_item&px=SolidRun-ClearFog-ITX <comment><USER2> > multiple 10 GbE SFP+ connections

That's normally quite expensive. That would absolutely be the killer feature of the board. Color me at least mildly interested.

[https://www.solid-run.com/nxp-lx2160a-family/clearfog- itx/](https://www.solid-run.com/nxp-lx2160a-family/clearfog-itx/)

> This carrier board features an array of 4 x 10GbE SFP+ connections (2 x 2) > and 1GbE RJ45 interface. Other features include 3 x USB 3.0 and 4 x USB 2.0 > port, 2 x mPCIe, 4 x SATA, up to 64GB DDR4 memory, eMMC, optional M.2, > microSD, and GPIO header

I doubt that you can actually use all of those at the same time. I do wonder how many PCIe lanes they've dedicated to all of this I/O. Those are the kinds of details that would make-or-break a product like this.</comment>


With $15 in Radio Shack parts, 14-year-old hacks a car - <AUTHOR> http://www.computerworld.com/article/2886830/with-15-in-radio-shack-parts-14-year-old-hacks-a-car.html

<comment><USER2> Not sure this means anything. You have physical possession of a car, you can attach to any system.</comment>


Omscs: The Revolution Will Be Digitized - <AUTHOR> https://www.cc.gatech.edu/news/620099/omscs-revolution-will-be-digitized <comment><USER2> The thread is filled with other OMSCS students, so I may as well throw in my perspective as a grad.

\- The instruction quality is comparable to free online courses (which is unsurprising since it's all delivered over Udacity anyway.)

\- I learned a ton

\- What Georgia Tech gets right is simple and a little sad: credentials matter. I learned a lot by going through a bunch of online courses and being graded, but a significant chunk of the value is just saying I have the degree. I wish that "I took a dozen MOOCs" carried the same weight as saying that you have an MS from a top-10 school, since in this case they really are exactly the same, but it doesn't. That's particularly true with arms-length interactions. Day-to-day my CEO cares more about the skills I picked up from the program, but when he's assembling slides about team for a pitch deck, the credential matters more.

Here's my full write-up: [http://writing.maxrosett.com/reflections-on-the- georgia-tech...](http://writing.maxrosett.com/reflections-on-the-georgia-tech- online-ms-in-computer-science.html)

Edit: Formatting

<comment><AUTHOR> > The instruction quality is comparable to free online courses

IMHO: the instruction (video classes) is comparable to GOOD QUALITY online classes. There're a ton of shitty online content.

And projects/exams are, IMHO, far harder.

But YMMV.

<comment><USER2> That's a good point. I haven't really come across bad online content, but that's probably because I've stuck to stuff coming out of top universities rather than random Udemy courses.

</comment></comment></comment><comment><USER3> SDE in AWS working in industry for approximately 10 years.

I'm finishing up my first semester, taking graduate introduction to operating systems (GIOS), and so far I'm super impressed with quality of the program (again, not sure how the other courses compare but I hear GIOS sets the bar quite high). In addition to the rigorous curriculum, the students actively chat with one another online; the current course has a very active Slack instance — paid out of pocket by one of the TA — where people chit chat pretty much every day, many of us sharing our frustrations with the projects that, as others have mentioned, drill the theoretical concepts into your head.

In short, I'm pleased with the program so far and look forward to the rest of the courses.

</comment><comment><USER4> I graduated in December. Before this I already had an MS in Finance.

Overall OMSCS was a phenomenal value. The lectures are hit or miss, but that's not where the value lies in general, though there are exceptions (Joyner's classes like Human Computer Interaction). The value of the classes lies in the curated projects that high class professors designed and selected to facilitate learning. I learned so much in RL and ML especially due to those projects, as well as Educational Technology due to a project I selected myself.

FWIW I was working full time as a new software engineer when I started the program and after a year it helped me move internally into a data scientist position where I've now been for 2+ years.

<comment><USER5> how soon after did you start the program after your first full time role?

<comment><USER4> Concurrently, actually, in the engineering space.

My path was BA philosophy -> MS Finance (worked as an investment advisor) -> after a year break I went back for a post-bacc certificate in CS during which I interned as a software engineer -> OMSCS, which I started the same month I started my first full time software engineer position. A year later I transitioned to a junior DS position, and am now a DS. I'm 30.

</comment></comment></comment><comment><USER6> Can anyone who is taking/has taken the program and who has a family and full time employment comment on how the time commitment fits into your life, both in terms of course workload and the overall length of the program? I keep finding myself looking at omscs, but I'm a full time swe and I have kids so the prospect of another major time commitment is a little daunting.

<comment><USER7> OMSCS grad, father, and full-time SWE, here, also currently enrolled in the OMS Analytics program. I had my first kid mid-way through the program, and it was pretty rough. Something's gotta budge, and for me, it was sleep. In total, I pulled about 15 all-nighters, give or take, and watched a whole lot of lectures holding an infant. Most of the all-nighters were for large assignments/projects. It's tough, but can be done. Some tips:

1\. Load-balance your courses. omscentral.com is an excellent resource for this, and I made sure that the workload never exceeded 20 hours per week (there's crowd-sourced statistics there). Pairing some of the more work- intensive courses with "easier" courses was very helpful, in retrospect.

2\. Spread out your courses. It's self-paced! You can take 1 course per semester, skip a semester, etc. Before my kid arrived, I front-loaded and took a 3-course semester.

3\. Watch lectures at 2x speed. This was clutch. Most of the content has very slow speakers, likely for clarity, so if you're a native English speaker, watching at 2x speed is usually reasonable.

4\. Be okay with mediocre grades. This was probably the most liberating aspect for me. In undergrad, I really cared about my grades. Not caring about grades in OMSCS (or caring more about learning what I want to learn) was more liberating. There were many times I submitted sub-par assignments because they just didn't interest me, or I would rather have spent time with my family.

Hope this helps. If you attend the program, join the unofficial Slack group (I run it). Happy to chat with you offline.

<comment><USER8> The grade thing is huge. I've always been a 4.0 type, pushing for As in every course, but it just isn't realistic here.

Bs work, I don't care about GPA, I'm trying to learn and get the degree at the end.

</comment></comment></comment><comment><USER9> If anyone is interested in OMSCS, I recently wrote up some of my thoughts about being in the program:

[https://medium.com/@mycahp/thoughts-on-the-omscs-program- at-...](https://medium.com/@mycahp/thoughts-on-the-omscs-program-at-georgia- tech-after-my-first-year-ed8ad9a0aeab)

</comment><comment><USER10> It seems like most people have done the Machine Learning or Computing Systems specializations.

Can anyone speak to the value or content of the Interactive Intelligence and Computational Perception/Robotics specializations?

<comment><USER8> Computer Vision is a somewhat outdated course that gives a good foundational set of knowledge in the field.

It's run completely by the TAs, it does have one project at the end that allows the students to explore a bit outside of the basics.

That's the only one in that specialty I've taken so far.

</comment></comment><comment><USER10> Has anyone here graduated from this program? I'm curious about the instruction quality and career prospects in comparison to in-person programs from similarly prestigious schools.

<comment><USER11> I'm about halfway through and also did my undergrad at GT. Overall I've been pretty disappointed. The lectures are just YouTube videos played through Udacity, and the quality has varied from okay to bad. TAs make a big difference, but the quality there is a huge range. Some classes have had really good interesting active Slack communities, while others are basically just a Piazza page with people asking for help on projects. If you were disciplined and didn't care about the degree at the end, you'd get a lot more bang for your buck just by watching the YouTube videos and reading the textbook, since that's basically the level of instruction you get.

<comment> barry-cotter > If you were disciplined and didn't care about the degree at the end, you'd > get a lot more bang for your buck just by watching the YouTube videos and > reading the textbook, since that's basically the level of instruction you > get.

Comparing it to my Master's which has even less faculty involvement I doubt it. Watching videos and reading the textbook leads to the feeling you know something. Doing projects and preparing for exams, that leads to genuine learning. You learn far more working through past exam papers or doing all the questions in the textbook than you possibly could by trying to absorb information passively.

</comment></comment></comment><comment><USER12> If you could actually register for any classes you wanted. Why matriculate so many students if none of them can get into classes?

<comment><USER13> Is this your first semester? The waitlists clear up shockingly aggressively when the semester starts. I'm always surprised when I get into a class from position 300 on the waitlist, but it always happens.

<comment><USER12> I'm halfway through the program. Some classes clear up, but I rarely get the classes I actually want.

</comment></comment></comment><comment><USER14> This is an ad and there are a ton of posts just singing the praises of this program. I call bullshit.

<comment><AUTHOR> First, this is not an ad. It's a post that was sent internally to students by the dean of the College of Computing in order to recollect the inception of the program.

Second, why should this be bullshit? I'm an OMSCS student, and others HNers are, too. Check the accounts: all of them seem in good shape.

I don't understand this attitude; if something gets praised, it must be a scam? Maybe it's just something good.

</comment></comment><comment><USER15> The amount of astroturfing for this blatant ad is staggering

<comment><USER2> I wouldn't say it's astroturfing. People who participate in the program just seem to be really enthusiastic about it.</comment></comment>


How to sell/find investors for finished iOS game? - <AUTHOR>

My question is where i can find Angel Investors to buy or to invest in my finished iOS game ? <comment><USER2> Got a demo to show off?

<comment><AUTHOR> We have youtube trailer, facebook, twitter, link-in etc... My question is where on the internet i can find those people? Forums/websites/emails.</comment></comment>


Owe Me Cash: Easy debt collector - Rails Rumble 2010 - Built in 48 hours - <AUTHOR> http://owemecash.com

<comment><AUTHOR> Our Rails Rumble entry - Beware facebook login doesn't work on that domain name - If you want to use facebook please login on <http://omecash.r10.railsrumble.com> \- Give us feedback! :)

</comment><comment><USER2> At what point does it send out a 300lbs guy with a baseball bat to my non- paying client?

<comment><USER3> We're building that into the next release. I'm sure the Amazon Turks will love this.</comment></comment>


Ask HN: What habits made you a better programmer? - <AUTHOR> - How you think about a problem - Pushing past resistance<p>things like that <comment><USER3> Noticing pain points. It takes time to develop a taste for good solutions. But when you modify or write code, and you say, "this is harder than it should be," this is a code smell and there is a better way to globally solve the problem.

Thinking first, writing later. When practicing for the ACM programming competitions in college, I discovered that when writing code before understanding the solution, I eventually needed to start over. I have never seen a counterexample.

Learning new things. Every year I try to learn a new major skill. Two years ago I learned Common Lisp, last year I hacked on some AI textbooks, and this year I'm teaching myself how to build websites in Python. Try for some variety - Alan Kay said "Perspective is worth 20 IQ points," and while I make no standardized testing claims, learning from multiple fields can connect the dots in interesting ways.

Reading code. Norvig's PAIP knocked me out of my Object-Oriented rut and changed how I think about coding problems.

Working with smart people. Surrounding yourself with motivated and effective workers has a great multiplying effect on your own productivity.

<comment><USER4> I definitely won't disagree with anything you said in the general case, but for this:

 _Thinking first, writing later .... I discovered that when writing code before understanding the solution, I eventually needed to start over._

I think this may depend on how and when you think most effectively. Having the discipline to be productive in pure thought is impossibly difficult to quantify. At times I feel productive working that way, but other times just writing code helps me think through things faster. I type fast so it's not a big burden to type a lot of stuff even if I have to delete it.

Of course, sometimes just drawing things out on paper helps as well. I seem to recall Dijkstra making some criticisms of that, but for me it is often highly effective.

<comment><USER5> There's no clean path with regard to this.

Either you plan too much ahead and you end up tweaking your design forever, eventually building high-level cruft code that still won't get anything done because you don't dig deep to the ground to find the real culprits of your solution.

Alternatively, you plan nothing at all and end up rewriting your program several times because you just won't see the big picture as you're just digging up dirt from many different spots.

I think it works best if you plan only as much as you initially can and then start coding a proof-of-concept version as quickly as possible. You can only plan what you know of, and it's not much at first but it's something. Quickly getting to coding helps you understand the problem better, and you _will_ throw away a many approaches that turn out to be suboptimal or solutions to the wrong problem, but there's nothing wrong with that. When the coding brings in more knowledge, then you can plan a bit more, and repeat.

If you're good, you can do that most of the most of the time. A conservative estimate might be half the time. More importantly, you will never hit the optimal planning versus coding point but you wave around on the both sides, sometimes planning too much and sometimes coding too much.

Experienced programmers can keep the amplitude of that zigzagging low, inexperienced programmers rush from endpoint to endpoint doing too much either.

<comment> mkr-hn Since I'm still in the early stages of learning to program (past the "durr what are for loops" stage, but still not good at a language), I've found that it's nearly impossible to really plan anything out.

I can plan out what I'll put stuff in and the names of the classes and methods that'll work with data, but I'm clueless until I start trying to implement the idea.

I suspect that once I've done enough things, it'll be easier to plan. I know when I go back to any of my old C# projects, I keep slapping my forehead and am able to see other (often better) solutions.

So I think the better advice is: Try until you know what you're doing, then toss it out and plan around all the terrible mistakes you made.

<comment><USER5> Quoting myself: _You can only plan what you know of, and it's not much at first but it's something_. :-)

</comment></comment></comment></comment></comment><comment><USER6> Taking a nap.

Seriously, the most difficult problems I've faced have been solved easily just after taking a quick nap (30 - 40 mins). Most of the time it comes to the point that there's no solutions in the horizon, I'm pulling my hair out and biting on my keyboard and then, a quick nap later most of the problem is solved in 20 mins when I sit in front of my computer again. It's got probably something to do with unconcscious mind.

But the problem is employers may not see this "sleeping to solve problems" act as productive as you do. I read that Google has "nap rooms", and I'll definitely have one of those when I start a company.

<comment><USER7> Actually by taking a nap you are doing something really cool.

Let me explain:

You are actually inviting your right hemisphere(the creative side of your brain) to come out and play. The right hemisphere cannot be forced into thinking that much so by taking a nap you are actually letting the unconscious work for you.

 __As a really interesting side note, Thomas Edison used to take a nap whenever faced a difficult problem. He used to nap with ball-bearings in his hand and when he would fall into a deep sleep dropping the ball-bearings would wake him up, and he would wake up and tackle the problem. :)

<comment><USER8> I've heard this left-brain right-brain stuff before and I'd like to know where it comes from. Do you have any sources you can link to?

<comment><USER9> It's related to early brain research which discovered some left right specialization. Medically it's been mostly debunked, but for some reason "Pseudo Science" people really latched on to the term.

PS: By "debunked" it was discovered that the brain has more plasticity in how and where specific tasks where preformed that initially assumed. Also the high level understanding of what doing "Math" or "Poetry" has little connection to how the brain actually does this stuff. EX: Some people can count time accurately why reading other people can't. The most probable explanation as you grow up the brain chooses how to approach high level problems in a fairly arbitrary fashion.

</comment></comment></comment></comment><comment><USER10> I'm a big fan of technologies that have steeper learning curves, but pay dividends over time. Examples are: Emacs, Lisp, XMonad, git, my Kinesis Advantage keyboard, swype, etc. It's nice when technologies are user friendly or obvious to use immediately (like Quicksilver), but If it's something I'll be using all the time I go for long-term efficiently over early user- friendliness.

<comment><USER11> Are you a colemak or dvorak user?

I agree with you on all of those items. It's a little scary, actually.

</comment></comment><comment><USER12> 1) Being conscientious, actually caring about the work I put out. Spending that extra hour or two or four after I am 'done' with a feature, cleaning up the layout, making sure the field level validation all works, testing alternate paths, adding a few bells and whistles.

2) Learning how to communicate effectively. Keeping interested parties in the loop at all times. Not hiding mistakes or difficulties, or waiting until the last minute to let a PM know that a task is going to be late.

3) Not falling into the 'stupid user' trap. Your users aren't stupid. They know their business better than you do. You need to understand and accomodate their workflow, not the other way around.

<comment><USER13> 1) is very important for me too. Many people will say 'oh don't take your code so personally' but that just doesn't work for me. When I write something I want to be proud of it and I'm going to feel bad if it doesn't work even if it wasn't my fault or responsibility.

Also agree on 3) If a user asks for something 'stupid' you can't just shoo them away. There's a reason they asked and your job is to find out what that reason was - and to come up with a solution for your client that fits the rest of the system. The client may not know what they want but they do know that there's a problem that needs to be addressed somehow.

</comment></comment><comment><USER14> Learning. I'll probably be in the middle of learning something new and interesting the day I die. Some on here will disagree with me, but I'm a huge advocate of learning at the expense of doing. Spend time to learn how to not only do something, but do it _well_. After all, most programming tasks are only useful for a limited time. Knowledge is usually useful for much, much longer. Sometimes I'm surprised at how useful useless facts really are.

Plus if nothing else, you'll be able to do that task much faster the next time.

<comment><USER15> to add to that.. reading. I spend a lot of time reading, books, documentation, forums, and blogs

<comment><USER14> Good advice, but remember what Einstein said:

"Any man who reads too much and uses his own brain too little falls into lazy habits of thinking."

To me, the best readings aren't ones that I learn directly from. They're the ones that spark thought processes inside my head. I haven't read past Chapter 2 of pg's "On Lisp", but I still consider it one of the best books on programming languages because it changed how I think about them in a lot of ways.

</comment></comment></comment><comment><USER16> Heavy caffeine usage and liberal alcohol usage on occasion.

Avoid both of those.

When I have a a problem I do one of two things: 1) I work on trivial things like code cleanup and reorganizing things, or 2) I get my head completely out of the computer. Go for a walk. Sit outside and just look around for a few minutes.

The anti-pattern here is popping off to look at your email, FB, or HN. It keeps the brain active in context-switching mode, instead of settling into one context and having it work on the problem behind-the-scenes.

<comment><USER17> >Heavy caffeine usage and liberal alcohol usage on occasion.

>Avoid both of those.

I'll keep it short and sweet. Family, religion, friendship ... these are the three demons you must slay if you wish to succeed in business.

<comment><USER18> Ideas like that are a fine way to lose before you even start.

<comment><USER17> ...... It was a quote from The Simpsons.

You know, a funny joke? Haha?

WOOSH.

</comment></comment></comment></comment><comment><USER19> 1\. Embracing paranoia - enumerating everything that can go wrong with my code and testing for it. Over time, learning to think of more things that can break.

2\. Writing down every question that occurs to me about the technology I am working with, at any point, specifically the behaviour of libraries and nuances of programming languages: I am not an expert in any programming language. Then chasing those questions until they are resolved.

3\. When stuck with a slippery bug, attempting to reconstruct the bug in a toy program. If reconstructed, fixing it is easier. If not, I know it's not where I thought it was. Sometimes I never make it as far as actually writing the toy program; the intent is enough.

</comment><comment><USER20> Reading.

Programming is 10% writing code, and 90% reading code. Reading your own code (debugging, refactoring, coming back to something you wrote on Friday on Monday), and reading other code ("why doesn't this library work?").

Once you learn to read, a number of things happen. You are no longer a slave to your libraries; you can open them up, see exactly what they're doing, and either change your mental model or change the code. You don't have to get stressed out about "coding guidelines" anymore, because you actually understand what the code means. Inane details like tabs versus spaces and cuddled elses or whatever don't matter anymore, because you have seen all the possible combinations. And, you pick up the style of your peers, because you aren't coding in a vacuum anymore.

I could go on and on, but if I boil it down to one action item, it's "when you have a problem with a library, read it". Everything else comes from there. (And before you know it, you'll be mentioned in the Changelog of everything you use! Good for getting your next job.)

</comment><comment><USER21> I know it has probably been said a million times before, but I have found that in many contexts, trying to tackle problems in a purely-functional style has helped me immensely. To that end, learning languages like Scheme and Haskell forced me to think of programs in a more algebraic fashion -- so many things can be accomplished in a concise, readable, maintainable fashion using basic functional concepts like function composition/bootstrapping, closures, and higher-order functions. Furthermore, because much of it is typically referentially transparent, code written in this way is often fundamentally "safe" in the sense that it lacks side effects, making it much less likely to segfault or do catastrophically bad things.

Thinking in a functional fashion also made it easy for me to pick up JS and start writing event-driven code almost immediately, because so much of modern JS relies on proper understanding of closures and asynchronous events. Furthermore, if you find you like functional programming, I also highly recommend teaching yourself Church's basic untyped lambda calculus; I found that it helped give me a much better understanding of the basic underpinnings of so many languages. Similarly, having an understanding of the fundamental concepts that underlie all programming languages -- such as the differences between call-by-value and call-by-reference, or static and dynamic scope, or the various kinds of OO systems (prototype-based, class-based, mixins) -- is really important. My knowledge of these has not only made it really easy for me to pick up and learn a language extremely quickly, but has also saved me on more than one occasion from a pitfall that I would have otherwise made (such as forgetting that older versions of Perl use dynamic scope by default).

Also, as many other people here have mentioned, coding up solutions to problems from ACM competitions, Project Euler, Google Code Jam, etc. is a great way to get good at just _coding_. It is also a great way to familiarize yourself with a language.

</comment><comment><USER22> I work on what is most exciting to me and then switch when the excitement wears off, switching back again when the excitement comes back.

If nothing is exciting, if there's resistance (usually from lack of sleep, lack of exercise) then I focus on restoring my routine, and working on something easier like copywriting, email, invoice admin etc. until the excitement for something else wells up again. But I keep working. Often you need to just press on before the excitement comes back.

In the long term, I pick technologies I'm excited in, even if they bring short term costs. Connecting the dots, this process has lead to near-perfect strategy in hindsight.

This is counter-intuitive, but embracing NIH has actually made me a better programmer. It's the spirit of vertical integration. It's taught me how to do things and developed my understanding. Rather than using say an SMTP client, if I don't know how it works I dive in and write one myself. It costs the project in the short term, but in the long term the project at least has one more programmer who understands the nuances of another protocol.

Imagine a Google that outsourced their filesystem, data center, server racks, JS engine, browser, caching, proxying, map/reduce, machine learning, DNS, etc. Would they be as good as the Google of today? That's what separates IT from hackers. IT configure and use existing software. Hackers write their own. IT know how to "cobble together" things. Hackers understand things. Without the intimate understanding that comes from NIH, there is no room for the hack.

Being a better programmer is a long term motivation, and it's often the methods that pay off in the long term that contribute most towards this goal.

<comment><USER23> I've found that when "nothing is exciting" it's almost always due to the "resistance" you mentioned. Realizing this has really helped me to avoid getting discouraged when it seems like the thrill is gone.

</comment></comment><comment><USER24> Knowing when to stop.

When you reach a seemingly impassable problem, talking it over with other people and then sleeping on it will make everything clearer come morning.

If you work constantly you are a worse programmer than those who know to take breaks. These are the people who are thinking about what they're doing.

<comment><USER25> That reminds me of my worst habit as a programmer: I want to solve every problem myself, instead of asking for help.

I certainly don't recommend quitting every time you have a problem you can't solve in half a hour, but there's a happy medium between that and wasting days (while you're getting paid, or at least wasting your project's time) working on something that the guy in the next room could sweep away in ten minutes.

</comment></comment><comment><USER26> 1\. unplug. no chat, no web, no email, no phone.

2\. Find a work flow that keeps you moving forward no matter how slowly. here is mine. Basically design, top down then code bottom up, testing each piece as you go. An example of when I finally get to coding. a. write the comment for the function b. write the signature c. write the tests d. write the internals of the function

It will never almost never work out that perfectly but you should have the goal that, when you are done with that function you should never have to look at it again*

* you will. I do. Being perfect would be nice, but it just isn't going to happen.

</comment><comment><USER27> Don't assume things.

When you're developing, there are a thousand little decisions to be made. Don't assume that the server will be up before the client. Don't assume that the file you open will be writeable. Don't assume that the database is there. Don't assume that the user knows what you know. Don't assume everything works.

Maybe it's because I spend lots of time in teams developing large (overly) complicated systems, but a common problem is simply finding out _what went wrong_. Strictly speaking, you can sometimes accept something as a precondition if it is explicitly stated as such--but you still at a minimum need to at least fail loudly and obviously if it doesn't do what you expected. Silent failures suck.

Don't assume anything while debugging, either. As mentioned elsewhere, when debugging I find it useful to take the symptom and think of _every possible failure_ that could could cause the symptom. Then, start paring down the list by doing more tests. Do not assume anything. Don't assume the cables are connected. Don't assume the code is current, or the driver is working, or the the library documentation is correct. Verify, verify, verify.

By all means, use your experience to prioritize your search space. I personally prioritize stuff that's easy to check, or stuff that's known to have a problem. Of course, I generally suspect my own code long before turning my gaze toward third-party components. But don't assume! Remember the old saying, "it's not a compiler bug?" Well, yeah--that's really the last thing I'd suspect. But if I ruled everything else out, I'd at least do a Google search to see if anyone at least brought up the possibility.

But of course, I've never gotten that far. So far, every debugging problem has been reducible to a failure to check my assumptions.

There's a fantastic Mark Twain quote that I was amazed to find the other day; apologies if I've included it here before: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."

<comment><USER28> Hugh Akston in Atlas Shrugged: "Contradictions do not exist. Whenever you think that you are facing a contradiction, check your premises. You will find that one of them is wrong."

</comment></comment><comment><USER29> For me, it has been writing small little utility projects using technologies that I'm curious about.

Recently it was jQuery and the Play! Framework -- for the longest time I was trying to think of some "grand" project that I could write to use them all together and become the master of all that is web... then a year went by and I continued to try and figure out what this ultimate project would be.

What a waste.

Then one Saturday I was bored and sat down and wrote a simple collection of AJAX utilities that do the most basic crap that anyone could write - <USER2> those two technologies. It helped get me over that hump and I learned a lot about the two techs I was curious about.

I went ahead and stuck the utils online for anyone to use and moved on with my life.

It was a great exercise for me, and a method of write/release I plan on using from this point forward for just about anything.

</comment><comment><USER30> So I do a lot of stuff that's not programming (dealing with managers mostly). But I've begun to practice a simple routine - make tea, close my door, and do nothing but write code from 2 to 4 (or 1 to 3, or 1:30-3:30). Every day.

</comment><comment><USER25> The first habit I try to impress on junior programmers is not to be satisfied when you've fixed a problem: you aren't done until you understand what went wrong in the first place, and have a plausible explanation as to why the change you made fixed it. (Bonus points if you go looking for other instances of the same problem.)

</comment><comment><USER31> I believe that the quality of the code you write only shows itself over time. Every other metric we use to measure quality is subservient to one simple truth. How does your code age?

How easy is your code to modify later when you need to add a new feature? I think that's the only measure of good code that I trust. I get a little proud of myself when I need to modify something I've written previously to add a new feature and it's relatively easy. So I look back at how I wrote it then and try to learn from it. The opposite is also true. If I need to modify my code to add something and it is truly painful then I know I did something wrong way back when. The same is true for bugs found. If every bug found requires massive code changes than I did a pretty piss poor job initially. But if most bug fixes only require a couple of lines than I did well.

This makes identifying good and bad practices especially difficult because it requires that you stick around for things to fall apart. This is one of the reasons that commercial software sucks so much and why consultants leave giant messes in their wake. The short-term priorities of business conflict with the long-term reality of determining software quality.

As a developer it's your obligation to learn from your past mistakes and better yourself.

</comment><comment><USER32> Maybe it's my undiagnosed Adult ADD, but:

* turning off Twitter & IM

* closing email and Google Reader

* headphones headphones headphones

* big ol' notepad for notes and doodles

Kill as many distractions as possible, make the ability to create & think ridiculously easy and just keep on truckin until you have something to test.

<comment><USER33> with you

</comment></comment><comment><USER34> Three things: learning one editor (Emacs) really well, learning new languages that force me to think differently, and as am6100 said, writing a lot of programs.

<comment><USER35> I've used emacs for 9 years.

Last week, on a whim, I went cold turkey to vim.

The result: I'm probably staying with a (heavily modded) vim.

I added the standard bash/emacs/OS X input keybindings to insertion mode.

It feels like the best of both worlds.

The moral: it's good to branch out and try new things every now and then. You might get surprised.

<comment><USER36> I went the other way this year and am now almost totally in Emacs. I recommend trying the vimpulse package for Emacs if you ever want to come back to the dark side.

</comment></comment></comment><comment><USER37> Tackling smaller chunks of work at a time, conceptually.

That might mean committing my changes more frequently, refactoring smaller blocks of code, or avoiding the temptation to fit a lot of functionality in one class/function/file.

</comment><comment><USER38> Never just shrugging some problem off with "boy that's weird." I usually can't let something go until I understand what caused an issue. It eventually became unrealistic to chase down every oddity, but I've done enough of them to learn a lot about different pitfalls.

<comment><USER39> Funny because that's one of the things that I've learned - when to let something go as 'that's weird' and just solving the problem without spending days digging into root causes. Sometimes it's worth it, but usually it's taking time from getting other priorities accomplished.

<comment> mkr-hn When I run into a perplexing thing like that, I put a tag on it so I know to come back later once my mind has had time to work on a different problem.

</comment></comment></comment><comment><USER40> While I get my hands on a new technical book, I keep all the new terms and concepts that show up in a Google Docs document, just a list of them. Every now and then I take a peek at such list. It helps me increase and/or reinforce my knowledge around the area.

Before committing anything, I double-check everything, refactoring the code I have modified/added. This is easy because, once you have your new functionality or fix working, maintaining the new correct behavior as you modify the code is low-risk if you do it step by step.

English, as being my second language, is an important part of my job. I try to read all the books, blogs, movies, and so on in English. Every time I come across a new word, I look it up in wordreference (plugin for chrome), and add it to a list in Sidenote (mac app). When I need to communicate through email, I sift through that list looking for words that may fit in my message. It is a simple practice that has helped me out big time in uplifting my skills (of course I share this list with my friends!). Certainly this not directly related to programmig but, as I see it, if you want to improve as a programmer, you're going to need to become rather fluent in English.

Writing a blog. Especially invaluable when you get feedback of your posts. Folks out there shall give you a kick in the ass more often than you expect. Expect and embrace them. It's a great way to grow up.

Get to know that the finest blogs, books and people are in your domain. For example, years ago I programmed in Java, usually building web sites with the help of very known frameworks (Spring, Struts, you name it). I thought I was quite competent until I come across a book called "Effective Java" by a dude named Joshua Bloch. Needless to say I was struck by it and I ended up feeling like I knew nothing (literally). You can't program in Java and at the same time not know who Bloch, Goetz, Unble Bob, and so on. Same with Lisp and Norvig, Siebel, Graham.

I always strive to keep up with the basics. This is the killer skill that shines when everything else I try fails. With a new technology, starting out learning the ropes from the top abstraction layers makes me feel competent because I can get my job done, plus or minus. Basics alone aren't that helpful, but when something arises that steers from the standard way of doing the stuff promoted by the top abstraction layers, a great deal of the times I will need to dig right into the core in order to be able to solve my issue. Well, plus or minus, I personally call this the Onion Theory. This is related to the 'darkness surrounding you' concept explained above. Awesome.

</comment><comment><USER41> 1- semantics matter. Names should neatly describe what they refer to.

2- avoid mutable variables. Using the same name for two things is just another way to get tripped up.

3- if you're going to ship it, try to stay in the lower (50%) range of your abilities. This is how to get things done lightning fast in my opinion. Work on your skills and improve every day, but to produce something functional and enduring you should be technically conservative and produce something you thoroughly, thoroughly understand.

4- Your abstractions should be accurate, precise, and cognitively manageable.

5* Non-programming organization skills matter. Identify stakeholders, gather requirements, set priorities, PRODUCE, get feedback... repeat.

</comment><comment><USER42> I became a better programmer by writing a lot of programs.

<comment><USER37> This will definitely help, to a point. Reflecting on programs you've wrote and seeing the mistakes you made is also important.

I've had colleagues that had wrote hundreds of programs, but they were mostly the same boilerplate, same glue, with different business logic. Writing a lot of different, varied programs, is key.

</comment></comment><comment><USER43> Being aware of and managing my ignorance.

I don't know if I can describe this very well, and I've only recently started explicitly noticing this about myself, but I seem to have a well-developed intuition of how much I am "in the dark" about a particular domain, problem, technology, library, behavior, etc. I seem to sense well (and can back up with explicit arguments if necessary, but it stars with a feeling) when there's too much darkness around me, and then my primary focus must be on learning/understanding/tinkering/iterating to make it go away, rather than groping around in it. But it's also important to know when to stop, to avoid the danger of depth-first devouring of information that can consume too much time (not unlike "wikipedia surfing", when you suddenly come to and realize you've been reading it for three hours).

I never imagined this to be any kind of special ability, until I started noticing that some otherwise competent people seem to lack it. So perhaps it's a useful habit, and perhaps it can be cultivated, but I'm not sure how, except by trying to be aware of your ignorance as much as possible.

This principle seems to apply in different situations: when designing, when debugging, when writing code to interact with someone else's code. It always pays to maintain a mental model that includes the gaps, and to estimate how important filling the gaps is.

For example, when debugging a difficult problem, like an elusive bug or mysterious behavior, I usually make conjectures of where the problem could broadly originate, and try to rule them out one by one. Maybe I can ask if things are already "bad" after this place or before this place in the source code. Maybe I can vary or reduce interaction with other systems to rule out the problem there. I'm half-explicitly half-intuitively dispelling the "darkness" around my understanding of the problem, forcing it to hide in fewer and fewer places. Suppose that one of the plausible conjectures is that this mysterious behavior may be caused by a bug in a core library or the compiler/interpreter of the language. I may need to "dive" there and start reading much unfamiliar code to learn and understand those domains, but I'm going to postpone this until absolutely necessary, and rule out easier domains first. I'm managing my ignorance explicitly.

(Now that I'm thinking about it, maybe this is why many people, including myself, often prefer debug prints to working in a debugger - debug prints are good at giving you useful negative information: "it's still OK here, the bug's not here". When working interactively with a debugger, this is more difficult to get at).

Or imagine that you're thinking about how you will use a standard component - an SQL database, a "NoSQL" database, a network library, S3, a language, anything. Assume you understand the API. How much do you know about the constraints and limitations of that component, and how much _should_ you know? I don't feel the need to throw together a piece of code that uses connect(), accept(), send() etc. before I use sockets pervasively, but if it were my first time writing a network client/server, I probably would. I've never used S3, so merely reading about it and reading the API wouldn't be enough to start something big using it. I'd have to tinker a little first, get some intuitive, dispel some darkness. All this seems rather trivial to write out, but I think that we fail to act this way surprisingly often. I've seen people write multi- threaded programs in pure Python, complete with starting multiple threads, using locks, etc., oblivious to the existence of the GIL and the fact that they're losing rather than improving performance. I've almost done the same thing myself when I was new to Python (I still think that Python hides this aspect of its behavior much too well from outsiders and beginners, and am a little chagrined over it).

Premature optimizations usually fall under this principle as well. When I'm optimizing prematurely, it's because I am not uncomfortable enough with the amount of darkness around the behavior of my system. I don't actually have a good understanding of where the bottlenecks are now or may be in the future, but it doesn't bother me _enough_ ; I'm groping in the dark without realizing it. If I do realize it, I will step back, try to look at my system with a critical eye and do some hard measurements before I try to optimize. This will usually be a good thing.

<comment><USER44> I have a lot of "darkness" around me concerning threading, but isn't it a net win even with the GIL if the threads are mostly waiting for IO to finish?

<comment><USER45> I think he means attempting to solve the 'symmetric multiprocessing' problem using threads, rather than using threads for sensible things like IO- forking/event-driven, asynchronous stuff.

</comment></comment></comment><comment><USER5> Assuming I don't know shit yet (but that sometimes I _do know_ something).

When I was younger, I hoped I knew pretty much everything I needed to know. Oh boy, that was hard. That effectively cut me off learning because if you don't admit you don't know something you can never learn anything. My learning was diverted to many impractical programming mindgames instead of bare hands-on programming.

Luckily, programming is a very binary thing. A program either works or it doesn't. If you don't know something or you don't understand something, you can't solve the problem. Enough of the cases where someone smarter had written code that I just couldn't have written the same way or as elegantly finally returned me back on my feet.

Then I dipped slightly to the other side of the axis. I assume I don't know anything about some problem or new piece of code until I study it enough to confirm that certain similarities to what I've seen before do exist. The downside is that it takes time until I find my confidence but eventually the magic will dissolve, I see how the program works, and I finally touch the code and start making modifications. But I remain very careful unless I'm really, really, really sure I know better to make a big modification.

While it is stressful to the ego, for me it's a much better way.

</comment><comment><USER46> Really taking the time to learn your current framework really well. For example, my first rails site was written with a shallow understanding of both rails and ruby, and I ended up writing reams more code than I needed to, and the code I wrote was usually rolling my own when rails/ruby offered a cleaner simpler and more robust way of doing it.

In other words, don't go against the grain of whatever framework/library you are working in. Learn the path of least resistance.

</comment><comment><USER47> Prototyping semi-trivial cases. What I mean is that a solution of a problem might require some parameter so I'll just pick a value of the parameter that makes it possible to solve the problem in a brute force fashion and evolve the code base from that point. This is because I'm a visual and interactive thinker so any kind of feedback that helps me explore the problem space as soon as possible makes me at least twice as productive.

</comment><comment><USER48> I do a top down view and a bottom up view, even if just in my head. How should this look and function when it's done? What base classes will I need? Which parts go in between? Also, breaking up things I have left to do into small enough parts that they can mostly be done in a single sitting (obviously there are exceptions). Then I never have to leave feeling like I accomplished nothing.

</comment><comment><USER49> Persistence and time. A good part of programming can be self-taught, so you just have to give yourself the time and be patient with yourself.

</comment><comment><USER50> Making peace with the fact that I'm way too stupid to write bug free code.

This leads to a surprisingly large number of practical habits.

1\. I welcome code reviews. Some people can't stand their code being criticized by other people. To me the fact that someone else spends time improving my code is a clear win. Ego is not bruised if you start with assumption of being stupid.

2\. I seek out and use tools that help me find bugs automatically and understand my code better. Static code checkers like clang analyzer or cppcheck or pychecker or lint. Valgrind, good memory and cpu profilers, good debuggers. Source Insight (an editor).

3\. I see enormous value in continuous build systems and automated testing (be it unit tests or more holistic tests).

4\. I step through new code I write in the debugger just to verify that it behaves the way I expect.

5\. I stay away from complexity, both self-inflicted (like trying to be too clever when implementing something) or inflicted by the tool (e.g. I avoid using advanced features of C++). I avoid multi-threading as long as I can.

6\. I add diagnostics to my code. Logging, asserts in debug builds, built-in crash dump submission to my site for analyzing crashes that happen in the wild.

7\. I know that despite doing all I can to prevent it, the bugs will happen and will have to read my own code to fix them long after I wrote that code. Therefore I try to make the code as readable as possible for my future self. Balanced comments (not too much, not too little). No cryptic names for variables or functions. No long functions with complex logic. I take the time to make my code look consistent.

8\. It's better if other people sweat writing and fixing bugs in their code than me in mine. I look for high quality, reputable components instead of re- inventing the wheel. I would much rather use SQLite than write my own persistence layer.

</comment><comment><USER51> Googling.

I used to write a lot of things from scratch, unnecessarily. Whenever I find myself working at a level of abstraction much lower than the problem I'm trying to solve, I start googling. This has led me to django, grid 960 (css), jquery ui, etc.

These days, writing a new app usually means seeing how far I can get with Drupal modules first.

</comment><comment><USER52> The biggest difference between my younger self and now is that I know how to plan my programming passively. I've reduced my actual work time by 2-3 times and increased productivity 2-3 times by simply thinking about problems and how I'm going to solve them so that when I put down code it just flows.

</comment><comment><USER53> Surrounding myself with developers smarter than me.

</comment><comment><USER54> Code review. Oddly enough, it wasn't so much the issues that were raised by the reviewers that made me a better programmer (though they certainly helped), but the knowledge that every aspect of my code could be inspected, and I'd be expected to fix it, that forced me to double- and triple-check my work before sending it off. Since that time, even when I'm working on personal projects, I find myself coding defensively, and will often write sections of code a couple times until I'm satisfied that it is unambiguous, correct, and clear.

This has helped immensely when I've gone back months later and tried to figure out what I was thinking; now, it actually makes sense!

</comment><comment><USER55> Thinking about problems away from the computer always seems to bring about the answer. It seems like I do my best thinking in the shower, only problem is the usual 10 min shower sometimes turn into 30-40 mins.

</comment><comment><USER56> 1\. Learning to love learning new languages. I have a few pet projects which are slightly longer than hello world that I practice with.

2\. Accepting that code I wrote a month ago sucks. If it doesn't then I haven't improved/developed. That's really the point of refactoring. I do my best today and move on.

3\. Socializing. Yes, going out to hack/codefests etc. makes you better. BTW: Yes, you have to speak with other people/developers...sitting in the corner by yourself and drinking your latte is usually not enough.

</comment><comment><USER57> Test, test, test, test, test, test, test! Then automate as many tests as possible so that when you go and make a cup of tea you know you haven't broken anything :)

</comment><comment><USER58> If you're able to, pair programming with someone better than you (be it in the particular domain, paradigm, language, tooling, etc), is a /huge/ boon to learning.

</comment><comment><USER59> It is almost like when you learn to write. Each times you make an error and notice it, the next time you're going to write it right at first.

The first time you forget the name of the function, the second time you remember the name but forget the semi-colon, the third time you forget the underscore, etc. Meanwhile, you remember slowly those errors. In the end, you write your code without any mistake right out of your head.

</comment><comment><USER60> Taking breaks for tea/showers/walks in the fresh air is the one thing with the best chance of helping me solve a problem. Of course, this is only effective after staring at it long enough that when I eventually do take a break, I can't stop thinking about it (and I'm so embedded in the problem that I know enough about it to continue thinking without referring back to it).

</comment><comment><USER61> Understand the domain really well. You have to live and breathe it. Not just the specific problem you are trying to solve but the bigger picture. It will give you the freedom to make macro level decisions regarding your code that can have a high impact.

</comment><comment><USER62> My list of n things:

[http://quandyfactory.com/blog/41/top_10_programming_lessons_...](http://quandyfactory.com/blog/41/top_10_programming_lessons_in_10_years)

</comment><comment><USER63> Discipline to not check Hacker News while I'm coding....

</comment><comment><USER64> Sleeping with problem has helped me not just in coding problems but in many other cases.

</comment><comment><USER65> Participating in programming competitions like IOI, ACM, Topcoder, GCJ, etc

<comment><USER66> How does that help? To me they seem like interesting puzzles, but with little relevance to problems in practical projects.

<comment><USER65> Those improves your coding ability a lot. For example, If your application needs to scale well, you should always consider implementing efficient algorithms. Yes, you can use some open source libraries, tools, etc but someone has to write those using efficient algorithms. This is one of the main reasons, that companies like Facebook, Google are recruiting people using these "puzzles" or contests like Topcoder, Google Codejam.

</comment></comment></comment><comment><USER67> Thinking in terms of similarity rather than strict equality.

</comment><comment><USER68> Avoid over-abstraction (still working on this one myself).

</comment><comment><USER69> Caffeine. I'm surprised nobody has admitted this yet.

<comment><USER70> Too much caffeine is a real problem, though. Programming benefits from a calm and lucid mindset, not being manic and jittery.

</comment></comment><comment><USER71> Make a commitment to finishing something.

</comment><comment><USER72> self discipline and consistency.

</comment><comment><USER73> Have Discipline to go 100% not 95%

Keep notes - I use blogger.com

Write documentation - writing man pages has forced me to fix corner cases

Having projects with real users - they are annoyingly good at finding errors

Turn on -wall, keep coding until you get none

Often the best place to solve the problem is AFK.

Healthy body, healthy mind - combined with the above I like to bicycle, an hour in the pedals pays you back. Cooking proper food yourself from real ingredients feeds your brain.

TMTOWTDI - dabble in languages you don't use as your main such as Forth / Scheme / Assembler / J / Factor / Brainfuck

</comment><comment><USER74> Writing distributed code. Once your data is too large and your logic too distributed to run or debug locally, you are forced to become a much more careful programmer. I have to carefully read the code and think about what is going on, whereas before I often used debugging and stepping through the code as a crutch.

</comment><comment><USER75> edw519 arriving in 5..4..3..2..1</comment>


Sony to announce Playstation 4 on Feb. 20th, what are HN's predictions? - <AUTHOR> http://kotaku.com/5980715/is-sony-going-to-announce-the-next-playstation-on-february-20

<comment><USER2> Hmmm...maybe if they do end up using AMD chips like it is rumored here, it will breath some new life into AMD stock.

[http://kotaku.com/5896996/the-next-playstation-is-called- orb...](http://kotaku.com/5896996/the-next-playstation-is-called-orbis- sources-say-here-are-the-details)</comment>


Show HN: goPop: An iPhone case that electronically manages your cards - <AUTHOR> http://www.indiegogo.com/projects/gopop-electronic-card-management-system

<comment><AUTHOR> So this is my project that i've been working on for about 18 months. It's totally going to fail but im ok with that. The biggest issue I have right now is why its failing, I have no idea! If you could please tell me what you didnt like about the project that would be helpful.

Thanks!

<comment><USER2> I am your target customer (I think), I hate carrying around things in my pocket. But, this product doesn't really solve the issue. There are plenty of cases that hold cards... this case has a unique feature - it pops out cards mechanically. This doesn't solve the initial pain point. Infact, in my opinion, it adds a layer of complexity to a simple task. Now in order to eject a card, I need to open my phone (with password), open an app (I already have too many applications), find the card, then push eject. Not only is this more complex, but it's one more thing in my life that seems finicky. Something that could break, run out of battery, jam, etc - a simple card holder is a lot more appealing to me. I think you have a cool feature (can see where you left your card), but I'm not sure its enough.

Again, these are my thoughts. I don't know your business. Maybe I'm not your target customer. Wish you the best of luck as you move forward and figure things out. Hope this helps.</comment></comment>


Snagging creds from locked Windows/OS X machines using USB-Armory/Hak5-Turtle - <AUTHOR> https://room362.com/post/2016/snagging-creds-from-locked-machines/ <comment><USER2> anyone understand what exactly is the system broadcasting to the new DHCP server? I can't imagine any system is so bad to the point of sending anything more sensitive than a user name

<comment><USER3> The explanation is somewhat convoluted, but I believe they're impersonating a Windows server and convincing the target to send NTLMv2 credentials for the logged in user. Haven't looked at the protocols for a bit, but there may be some restrictions on when you're able to use this attack vector, e.g., local file sharing permitted, domain member, etc.

I'm thinking our intern might be willing to test out a few more theories and put together a more comprehensive blog post.

<comment><USER3> Check out [https://github.com/Spiderlabs/Responder](https://github.com/Spiderlabs/Responder) for some additional info and links.</comment></comment></comment>


Near-miss incident at Barcelona Airport caught on video - <AUTHOR> https://www.youtube.com/watch?v=1N5THRSp4hM

<comment><USER2> I expected to hear a lot of shouting over the radio.</comment>


Ask HN: ZFS for databases (Postgres) - FreeBSD or *Solaris ? - <AUTHOR>

I am finding measurable IO performance improvements in using ZFS compression on Linux for OLAP workloads. Given that the ZFS on Linux project is still moving to a feature complete release, I am considering an OS with a native ZFS implementation.
Although I am not too familiar with BSD or Solaris, I am considering putting the time into learning some admin skills on FreeBSD, or an OpenSolaris descendant like OpenIndiana, SmartOS, or OmniOS.
For systems where application compatibility is not a concern (a box only running the DB engine), does the HN community have any relevant details to share as to which OS's have advantages in this use case? <comment><USER2> I've used ZFS with mysql on both FreeBSD and Solaris (OpenIndiana specifically). The main problems I found with FreeBSD were not the ZFS implementation, but OOM (out of memory) errors killing off processes (like sshd). Solaris, though extremely annoying to use, offered up a 2-5x performance increase over the same hardware running FreeBSD.

<comment><AUTHOR> > Solaris, though extremely annoying to use

You can't drop a comment like that without details!

<comment><USER2> Annoying things I found while implementing solaris (open indiana). All my opinion and may not reflect other peoples experiences.

1\. Init > SMF - XML manifests instead of text configs? Very unnecessary. svcadmin took some getting used to, consulted the documentation frequently.

2\. Packages - Many packages are available, however we ended up compiling most of our software. That inconvenience was one of the main reasons we left FreeBSD.

3\. Chef - At the time there was very little we could do to automate these boxes in our infrastructure.

4\. SSH keys in LDAP - I don't recall if we ever got this working. (LDAP tree in Zimbra)

5\. ZFS Root - Required us to manually install the OS rather than having it provisioned

6\. Learning curve - Though not a strong point if you're dropping a new OS you don't know that well in to a production environment things are bound to break.

Those are the ones I can think of off the top of my head. But like I said earlier the performance increase was quite noticeable and worth it to the business.

</comment></comment></comment><comment><USER3> Don't do *Solaris, go with FreeBSD if you really don't trust Linux ZFS.

I used to administrate a Solaris box using ZFS. I'm still missing organs from those days (required for sacrifices to tentacled horrors).

Also I was initially confused by your desire to use ZFS with a database until I saw the "OLAP".

Godspeed.

<comment><AUTHOR> So far I find ZFS "sensible", considering I am no LVM expert.

So far volume creation and snapshots seem straightforward, and it only took a bit of research to find the page size and ARC limits that so far are giving me better than XFS on CentOS.

What future pitfalls am I looking forward to?

<comment><USER4> I run FreeBSD and Postgres on ZFS. It's been an entirely painless experience. No pitfalls to look out for from where I sit. Your use-case and results may differ.</comment></comment></comment>


Ars Technica posts their lengthy and in-depth 10.5 review - <AUTHOR> http://arstechnica.com/reviews/os/mac-os-x-10-5.ars

<comment><USER2> I'm really psyched for x-ray / Instruments (built on dtrace:)

<http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/5>

</comment><comment><USER3> Lengthy and in-depth is an understatement. Great job, worth reading!

<comment><USER4> Yeah, it took me all day to read (occasional bouts of reading between time spent doing actual work, I mean). Very well worth reading; I've been considering moving to apple for some time now, and this was a great overview of the kind of things I could expect from OS X.

</comment></comment><comment><USER5> Click through 17 pages, or become a "premier subscriber" and download the PDF.

<comment><USER6> or write a quick script to scrape the pages and output a PDF</comment></comment>


Tracking Honeybees to Save Them - <AUTHOR> http://nautil.us/issue/3/in-transit/tracking-honeybees-to-save-them <comment><USER2> July 11, 2013 edition</comment>


How the "focus on first" helps hide Google's relevancy problems - <AUTHOR> http://searchengineland.com/focus-on-first-helps-hide-googles-relevancy-problems-50253

<comment><USER2> Not the main point, but why would google.com search list google.com in the results for "Search engine"? You're at google already, so it isn't really a helpful result.

<comment><USER3> You drastically underestimate the number of people who think the Google is an Internet, browser, program, web page, etc. (I have at least one customer who thinks her school Internet and home Internet are different places because the start pages are different and The Google finds different sites on each. She uses Bing at school, but does not know Bing is not a Google.)

<comment><USER4> Well, she should learn!

</comment></comment></comment><comment><USER5> _"In January, I was invited to speak to Google's search quality team about issues I had with Google's search results. My topic? For queries where I know a subject really well, I often found Google provided some pretty poor results in the top listings along with the good ones. I wanted more perfection!"_

Oddly enough, I like it that Google isn't going to return only things that a given field's experts like. It's good that it's possible that if you hit enough criteria, you can be _one_ of the top search result even if you aren't what the authorities like. It keeps things interesting.

 _What's happening is that Google rewards longevity. AltaVista was around ages ago, gained a lot of links over time, and in particular links from other aged sites._

Again, I think it's good that Google is using the Internet's memory. Searching is seeking information. Altavista might just be the _term_ for information on search engines with the most discussion around it. Maybe it's the "best search engine" but perhaps my searches for "search engines" isn't about that but rather about how a search engine is built, how people interact with a search engine or what-not. There, the memory of the Internet is crucial.

If every search for X becomes "what is the best X in the world", the Internet will be rather diminished.

</comment><comment><USER6> I find it ironic that he's complaining about the relevancy of SEO companies on the first page.

After all, if they made it to Google's first page of results, so they have to be pretty good at SEO to get high results for the search for SEO... right?

<comment><USER4> Yes. That is why he used the term SEO, to show that google is doing worse than the SEO companies who are so good at getting to the front page.

<comment><USER6> Call me crazy, but wouldn't someone searching for SEO _want_ to find an SEO company?

<comment><USER4> Sorry, what I mean is that google is doing worse at protecting itself from being gamed by the clever SEOs who got to the front page without meriting it.</comment></comment></comment></comment>


A Cryptocurrency Millionaire Wants to Build a Utopia in Nevada - <AUTHOR> https://www.nytimes.com/2018/11/01/technology/nevada-bitcoin-blockchain-society.html <comment><USER2> Personally, I like seeing actions like this.

Even though the source of his funds may be questionable (FOMO?, robbing from the uninformed?, luck timing the market?), he's not letting his funds sit idle.

It's one man's personal moonshot.

If anybody is going to actively create a mini 21st century society that gets a lot of things right, it's a crazy near-billionaire who bought 67,000 acres of land and invests in a long-term team/plan to make use of it.

I'm very interested to see what happens.

<comment><USER3> If only there were any previous comparable attempts we could learn from ... [https://en.wikipedia.org/wiki/California_City,_California](https://en.wikipedia.org/wiki/California_City,_California)

<comment><USER2> There's a solid chance the current attempt will end up as just another failed planned city.

But that's what moonshots are all about.

If it were easy or likely to succeed, it would have been done 10 times already.

Songdo's not doing as well as hoped either: [https://www.citylab.com/life/2018/06/sleepy-in-songdo- koreas...](https://www.citylab.com/life/2018/06/sleepy-in-songdo-koreas- smartest-city/561374/)

But that's why we iterate and try again... or not "we" so much as bitcoin semi-billionaires.

</comment></comment></comment><comment><USER4> This is what you get when lucky people think they're geniuses.

</comment><comment><USER5> I'm sorry but I find it hard to trust the competence of any person who creates a company straight-up called "Blockchains". Such a money grab. Imagine starting Internet, LLC during the dotcom bubble.

</comment><comment><USER6> >"This will either be the biggest thing ever, or the most spectacular crash and burn in the history of mankind," Mr. Berns said.

At least he knows that there's a significant chance that it won't succeed. I'm also glad that somebody is doing something with their cryptocurrency millions, even if that something is as pie in the sky as this.

</comment><comment><USER7> '"This will either be the biggest thing ever, or the most spectacular crash and burn in the history of mankind," Mr. Berns said.'

Based on nominative determinism - [https://en.wikipedia.org/wiki/Nominative_determinism](https://en.wikipedia.org/wiki/Nominative_determinism) \- that someone recently referenced in another thread on HN, I think he might already have the answer.

</comment><comment><USER8> How to become a cryptocurrency millionaire: start off as a crypto currency billionaire and buy a bunch of useless land in the desert.

<comment><USER9> I can't imagine any land being _useless_. Even contaminated radioactive land can probably be put to use as a place to store more hazardous waste or weapons testing.

It never ceases to amaze me how dismissive people are of desert land.

This particular land is covered with vegetation, it's not even some barren landscape of endless sand dunes. All he'd need to do is drill wells and build out some PV arrays and it'd already be a place people could easily/affordably build relatively comfortable, albeit simple, lives. Hardly useless.

I'd certainly prefer acres of such desert land over bitcoin of equal value.

<comment><USER8> Sorry, but most desert land is pretty "useless". You can't grow crops, it's far from metropolitan centers, it's hot. Unless there is buried oil like in Saudi Arabia, or near a major city (eg Phoenix, Vegas), the land itself is pretty "useless" in a resource extraction sense. Even solar panels need to be relatively close to a substation that can handle it.

That said, the desert can still be beautiful to those the live there, and spiritual to native Americans with history there.

So the desert is interesting and cool, but not necessarily lucrative.

</comment></comment></comment><comment><USER10> Subtitle tells the whole story:

> _A man spent millions on an enormous plot of land near Reno. Now he wants to > build a community based on the blockchain technology introduced by Bitcoin._

He could have joined up with the Bitcoin mining group in Wenatchee WA, where they spent millions building custom "mining pods" to house the ASICs.

<comment><USER11> I'm not sure what that has to do with this person planning a town.

<comment><USER10> They could have combined their similar goals and pooled their money.

<comment><USER11> What are their similar goals? This guy is planning a town, those other people were doing crypto currency mining.

<comment><USER10> > _Every resident and employee will have what amounts to an Ethereum address, > which they will use to vote on local measures and store their personal > data._

Maybe repurpose the pods to hold ETH mining gear?

But you've caught me. I obviously don't know what I'm talking about. Congratulations, CyberDildonics, you've won HN today!

<comment><USER11> I don't think anyone wins when someone adds nonsense to a thread that then needs to be corrected.

</comment></comment></comment></comment></comment></comment><comment><USER12> This will be an expensive lesson in water availability.

<comment><USER13> They'll just use the blockchain.

<comment><USER14> Hydrocoin, whenever you want water simply open your tap and activate your smartphone app to deposit coins to the local M.U.D. at a varying rate starting at 1 coin / liter. As soon as the block chain completes proof of work your tap will begin to flow. If attempting to get water at a time of high blockchain volatility or transaction demand, please allow 12-48 hours for processing. It is recommended not to use Hydrocoin during hours of peak operation such as mornings or evenings due to expected load related delays.

However, I do like the ideal of literal bucket arbitrage.

</comment></comment></comment><comment><USER15> This is effectively funded by all the student loans and double mortgages that FOMO drove people to trade real money for virtual commodities at the peak of last year's bubble. I'm calling it. We have reached peak blockchain hysteria. This is "if you build it they will come" on the blockchain.

<comment><USER16> Judging by the charts, peak blockchain hysteria was around December 2017.

<comment><USER15> The speculative pricing bubble and the hype around the technology are two different things.

</comment></comment></comment><comment><USER17> if someone's gonna invest in these idealistic projects, I'd rather see someone invest in tech cooperatives based on block-chain, or just employee cooperatives in general.

</comment><comment><USER18> This headline screams non-article. I don't know how anyone who is not at least a billionare hopes to make any sweeping changes (let alone a utopia) in any context beyond a couple thousand people.

<comment><USER11> The article says that he has spent 300 million dollars and bought 67,000 acres of land.

<comment><USER18> Land isn't automatically useful/valuable. It does need to be developed. If you took the land area of a city, and then went out bush and asked how much it cost for the same area, it would be pretty much peanuts. Yet land prices in cities are orders of magnitude higher.

The land is really only the start, and I'm pretty damn sure you will need an order of magnitude more money than that to develop it into something usable by modern standards.

<comment><USER11> This is textbook moving goal posts. He has obviously spent plenty of money and didn't spend all that on the land. I'm not if you are really trying to say he spent 300 million on land, but that isn't what the article implies.</comment></comment></comment></comment>


How Long Will It Take for Batteries to End the Oil Age? - <AUTHOR> https://insideevs.com/batteries-end-oil-age/ <comment><USER2> It took oil a long time to end the steam age. The contexts where steam from oil worked as well as steam from coal lasted a long time because steam as a reservoir of energy is pretty useful.

It took turbines a long time to end the piston engine age. As in: they haven't. Not all ages end or necessarily end cleanly in one moment. Batteries might replace some oil contexts soon eg in mining. Or in shipping. Or in some specific electrical generator contexts like fill in supply.

If Brasil has a viable Ethanol economy, why would batteries be better? If we built an ammonia power economy, why would batteries be better? It's about a lot of things like energy density, access to inputs, portability, complexity.

What if algal fuel works out? What if buterate feedstock works out? Maybe the oil economy won't end, as much as morph?

</comment><comment><USER3> The power density for hydrocarbons is far better than for batteries, and actually using the power is at worst comparably tricky.</comment>


Ask HN: Best 'roll-your-own' blog framework? - <AUTHOR> I <i>really</i> want to like the idea of adding more content to my blogger, or starting up a medium blog, but part of me just wants to throw together my own thing where I control it from the ground up (or at least as far as the software is concerned since it will probably be on AWS). That being said, I'm something of a server-admin n00b, and I don't want to put up a leaky wordpress where I end up getting myself hacked by a 14 year old in Romania. What are my options? <comment><USER2> There are tons of tutorials online that detail workflows involving static site/blog generators (Hugo, Hexo, Jekyll, etc) combined with Git source control, continuous integration, and static hosting services like S3, Netlify, etc.

Netlify even does the CI/rebuilds via Git hooks, and their free tier is amazing.

I'd say this might be the way to go for you, as you will write your content locally, and pretty much own the entire process, whilst not having to deal with servers, and limited Linux admin requirements (although you may get exposed to some of that and you will learn).

You'll also get exposed to some DevOps concepts like source control, continuous integration, "cloudiness," and perhaps "serverless," etc. These are kind of hip/kitsche buzzwords, nonetheless, these are the current tech trends, and definitely here to stay, and the wave of the future...

</comment><comment><USER3> Github Pages would allow you to organize your blog by year/month then display it however you like: [https://pages.github.com/](https://pages.github.com/)

Uses Jekyll for template, [https://jekyllrb.com/](https://jekyllrb.com/)

I thought it would be cool to pop in [https://ckeditor.com/](https://ckeditor.com/) in the template and then auto- commit edits using Github's API.

</comment><comment><USER4> if you know _any_ js its really very straightforward to write a dynamic node server based blog platform in an afternoon or two or three.

using...

node.js - for js runtime on a server express - http & routing mustache - templates skeleton - boilerplate css so default is neat

i managed to write a seriously bad templated blog/pages server with relatively little experience... [https://github.com/seanbutler/crispy- system](https://github.com/seanbutler/crispy-system)</comment>


Ask HN: Inexpensive Google Maps Replacement? - <AUTHOR> Our Google Maps invoice went from $4.11/mo to over $1k/mo. What are some lower priced options you would recommend? <comment><USER2> [https://thunderforest.com/](https://thunderforest.com/) [https://stadiamaps.com/](https://stadiamaps.com/) Both OpenStreetMap based.

</comment><comment><USER3> What features are using? Bing, Here and Mapbox all provide good products (as do a bunch of smaller map providers), but pricing varies a lot based on what you are trying to do.

<comment><AUTHOR> We're just showing properties on a map. Nothing special.

<comment><USER3> I would start by checking what your traffic load would cost under Mapbox and Bing and if they're too expensive I'd start checking some of the smaller OSM based hosts mentioned in this thread.

</comment></comment></comment><comment><USER4> If you need well-maintained mobile SDKs, Mapbox's pricing model is a lot more straightforward. If all you need is basic mapping on the web, OpenStreetMap is adequate.

</comment><comment><USER5> We are here to help if you need geocoding: [https://opencagedata.com](https://opencagedata.com)

</comment><comment><USER6> hey! would love to chat with you about mapbox - what's the best way to get in touch? feel free to send me a note here - firstname.lastname@example.com

-Vanessa</comment>


JSLint, The Javascript Verifier - <AUTHOR> http://www.jslint.com/

<comment><USER2> It does catch one thing that my usual testing doesn't: trailing commas. I am in the habit of defining maps like this:

       var foo = {
           foo: "bar",
           bar: "baz",
       };

This works in Firefox, but not in IE. Arghhh!

Perhaps I should do it Haskell-style:

        var foo = { foo: "bar"
                  , bar: "baz"
                  };

I find that to be pretty ugly, though, and think it's easier to just omit the trailing comma. Reluctantly.

<comment><USER3> You can use Steve Yegge's js2 mode, it detects issues of this type and warns you.

<http://code.google.com/p/js2-mode/>

<comment><USER4> Just came here to post that. It really is amazing; incredibly handy for javascript development. (It even warns about redeclaring variables, all kinds of issues).

</comment></comment></comment><comment><USER5> Such a big fan of JSLint. Debugging thing is a lot easier if you de-lint your program first, because it gets rid of whole classes of possible errors.

For anyone using Komodo, there's an excellent JSLint plug-in: <http://community.activestate.com/xpi/kjslint-jslint-komodo>, though you're limited to the version of JSLint they bundle in the plug-in. If you want to manually integrate the latest version into Komodo, I wrote a guide here: [http://www.danhulton.com/blog/2008/01/16/integrate-js- lint-i...](http://www.danhulton.com/blog/2008/01/16/integrate-js-lint-into- komodo-edit/)

Seriously - de-lint your JS.

</comment><comment><USER6> Javascript Lint is a nice Spidermonkey-based syntax checker you can integrate into your IDE. I installed it with macports, but it's here: <http://www.javascriptlint.com/index.htm>

In vim, I do: :set makeprg=jsl\ -process\ % which binds :make to a syntax check of the current file. It's a cool thing to put in an ftplugin.

</comment><comment><USER7> Is there any particularly good, JavaScript-specific reason why the braceless version of if statements is discouraged?

      if (foo)
        bar();

Or is this just a matter of taste as it is with C, C++, Java, C#, etc.?

<comment><USER8> It's just a matter of Douglas Crockford's taste and he doesn't like them so you have to live with it.

<comment><USER9> Along with increment/decrement operators, fall-through cases in switch statements, foo['bar'] style property access/assignment, bitwise operators, and a number of other things.

His book ("JavaScript: The Good Parts") contains a lot of good information, but roughly half is what I would consider "style" preferences.

<comment><USER10> To be fair, he gives a very clear explanation of how he came to his opinion on case statements -- he started out favoring them. So it's more "opinion informed by experience" than just "opinion".

</comment></comment></comment></comment><comment><USER11> #Self Promotion Disclaimer - Eclipse Plugin for jsLint

[http://www.rockstarapps.com/joomla-1.5.8/products/jslint- ecl...](http://www.rockstarapps.com/joomla-1.5.8/products/jslint-eclipse- plugin.html)

</comment><comment><USER12> Unfortunately, JSLint objects strongly to using 'new foo()' without assigning the result to anything, which is a pain if you're using Prototype AJAX since firing off an AJAX request is done by calling 'new Ajax.Request(url, options)'. The only way to get around this seems to be to put parentheses around the statement - there's no way to turn most individual checks on or off, unlike other static analysis tools I've used like PMD and FindBugs.

I still use it - because that trailing-comma-in-hash-definition issue in IE is really annoying.

</comment><comment><USER8> I have yet to find something like JSLint that supports ECMA-357 (SpiderMonkey, TraceMonkey, ActionMonkey, Rhino, and Tamarin). Does anyone know of one?</comment>


Apollo 11 Program Alarms (1998) - <AUTHOR> https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html

<comment><USER2> Gene Kranz, in his book _Failure Is Not An Option,_ describes one of the simulator runs for Apollo 11 in which the Simsup (simulation supervisor) threw a 1201 alarm at the Mission Control team. The controller receiving the alarm panicked and called for an abort, and Kranz passed the abort order on to CAPCOM. Afterwards, the Simsup told Kranz, "This was not an abort. You should have continued the landing...You violated the fundamental rule of Mission Control: You must have two cues before aborting. You called for an abort with only one!"

The controller dug more thoroughly into program alarm codes after that simulation, and wrote a new mission rule specifying a series of program alarm codes for which an abort would be called. 1201 and 1202 were _not_ among those alarm codes. Thus, when the 1202 showed up during the actual descent, the controller was able to say, "We're Go on that alarm," and when the 1201 happened shortly thereafter, he could say, "It's a Go--same type--we're still Go." Shortly thereafter, history was made...not just because the MIT programmers had done their job well, but because the flight control team in Houston had also done their job well.</comment>


Ask HN: Name Test. Can you spell this... - <AUTHOR>

One question survey: Listen to a 5 second audio of a name spoken 3 times and type it out.
My personal network has already read it, so I need some fresh folks. I appreciate the help.
Clickable in the comments.
http://appv3.sgizmo.com/testsurvey/survey?id=520213&crc=b49c357d8769f6798c5d13defaad0621 <comment><AUTHOR> Clickable: [http://appv3.sgizmo.com/testsurvey/survey?id=520213&crc=...](http://appv3.sgizmo.com/testsurvey/survey?id=520213&crc=b49c357d8769f6798c5d13defaad0621)

</comment><comment><USER2> I did a similar thing recently but used amazon's mechanical turk - might want to give it a try if you want additional feedback.

<comment><AUTHOR> Thanks. I'll do that.</comment></comment>


reMarkable - <AUTHOR> https://getremarkable.com/ <comment><USER2> Heh, I was expecting some weird reStructuredText/Markdown mashup.

This is actually pretty interesting – e-ink tablet with a custom Linux-based OS, pressure/tilt stylus sensitivity and a solid build.

Would be great if it gets some traction, but the price seems a bit high.</comment>


Raytheon develops ray gun that causes unbearable pain at half a mile - <AUTHOR> http://www.dailymail.co.uk/pages/live/articles/technology/technology.html?in_article_id=482560&in_page_id=1965 <comment><USER2> Uh oh, reddit is leaking.

<comment><USER3> The domain dailymail.co.uk should be blacklisted.

<comment><USER4> I wholeheartedly agree - it is the worst paper in the UK and should be aptly renamed the Daily Shit...

</comment></comment></comment><comment><USER5> I'm investing in a copper mesh suit ASAP (copper mesh reflects microwaves). Actually, I wouldn't be surprised to see troops wearing mesh suits in the coming years as these types of weapons proliferate. I smell a new startup idea...

</comment><comment><USER6> Raytheon finally lives up to its name. (I've always thought they should be in the ray gun business with a name like that.)

</comment><comment><USER7> You can't blame Raytheon when they're dependent upon taking requirements from government dictate. I blame command economics. And bureaucratic whim.

</comment><comment><USER8> ...now I am become Shiva, the destroyer of worlds...

</comment><comment><USER9> You can't blame Raytheon for making a product that is incredibly in demand. I blame capitalism. And human nature.

<comment><USER10> I blame human nature too. What else can be attributed when large, potentially violent groups amass against trigger happy security forces?

Thankfully, no one needs to die now.</comment></comment>


SpaceX is leaking sensitive information - <AUTHOR> https://twitter.com/JustinFaler/status/1181270325247365120 <comment><USER2> This isn't new information. These are contractor forms for request to access to SpaceX. They're available to any potential contractor to SpaceX and are fundamentally public.

</comment><comment><USER3> [https://duckduckgo.com/html?q=site%3Aadmin.spacex.com%20file...](https://duckduckgo.com/html?q=site%3Aadmin.spacex.com%20filetype%3Apdf)

</comment><comment><USER4> This is an example of how NOT to disclose a company "leaking" info. Privately is always better for responsible disclosure imho.

</comment><comment><USER5> Or maybe they are incredibly transparent?</comment>


Pediff – tools for visually comparing web pages - <AUTHOR> https://github.com/Schibsted-Tech-Polska/stp.pediff

<comment><USER2> We've been using a similar tool ([https://github.com/BBC- News/wraith](https://github.com/BBC-News/wraith)) for a little while now and it's transformed our way of working - 50 page layouts x 5 responsive breakpoints verified with a high degree of confidence in minutes on every build.

Well worth the effort to take the time to set up such a tool, particularly if you have a large UI test matrix - we couldn't possibly verify all the different page layouts and sizes before we introduced wraith</comment>