Ask HN: How do you decide on when to leave/switch job? - <AUTHOR> Please elaborate on your reasons rather than one liners like boredom, pay hike, own business/consultancy, co-worker problem <comment><USER2> Not learning anymore. The previous job I was at was a rather boring one after a few months.

The company had already encountered most of the customizations clients requested and most of the new projects ended up being solely copy-paste work from older projects. This meant writing no new code but just applying older patch files and tweaking some config like the header and footer of the website.

Since I was not learning anything new anymore at this job it felt like a drag going to work.

I started interviewing for some other companies and one thing I wanted to be sure of was to have a job where I would actually write code instead of tweaking some config files all day long.

I have enjoyed every day at work since I decided to leave that company.

<comment><USER3> Agreed. A job needs to be mutually beneficial or you'll wind up hating every day of it.

I'm at a stage where I have learned a lot, but I find a lot of resistance to implementing my ideas for political reasons - e.g. in replacing our ticketing system, I drew up a proposal for something we already had licenses for, would integrate with our systems and provided features our developers would want. An unrelated team in America had been trialling some expensive software in isolation. I learned the software I was proposing, taught colleagues how to use the prototype, got positive feedback, got licensing sorted (free)... and my idea was swept aside because it wasn't the expensive software the guy in charge (who had approved my prototype) had already decided to go with.

Figured then there was little point in me learning stuff that would benefit this company because decisions have already been made, so I'm moving on.

</comment></comment><comment><USER4> Best thing I have on this is a quote from Steve Jobs : "When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.""

<comment><USER5> On a related note, I hate how that Aurelius quote is always cut off. The full quotation is, "Live every day as if it were your last: without frenzy, without apathy, without pretense." The point isn't that you should go party and have fun and not plan for the future, which the additional "without" clauses clarify. Aurelius meant that you should adopt an emotional state of peace and firm dedication. Because most people really would not party on their last day, if they knew. They would go about their business calmly, taking care of the most important priorities, making amends and sharing time with loved ones, ensuring that their affairs were in order and their conscience clean, and appreciating every detail of every moment as if it were infinitely precious. Nothing would upset them unduly because they would know nothing will affect them anymore soon.

Similarly, you probably wouldn't want to wake up and go to an awful job. If doing your job makes the world a better place, you can justify going because you know you are building a legacy, even with your final moments. If you're passionate about it, you can justify it. If the job allows you to provide for your loved ones, you would go even on your last day.

So Jobs like many others misunderstood the quote out of context but reached the conclusion Aurelius intended anyway. And that conclusion is good advice! If you're just doing the minimum to skate by, not really thriving, you're probably selling yourself short. Unless you have some other reason for working that gives meaning to your life (e.g. kids, funding a passion project/hobby, religion), it's just not worth going to a shitty job just for the paycheck.

<comment><USER6> These are some great comments; thanks for these!

</comment></comment></comment><comment><USER3> What I call the Dilbert-o-meter.

When you start noticing too many Dilbert comics acted out in real life, it's time to leave.

<comment><USER7> That's a pretty good rule. I worked at a telco and a co-worker pointed out that the seemed very likely that Scott Adams had hidden cameras and microphones in our offices.

When Dilbert-like rules and decisions start showing up to frequently, it's time to leave.

Generally speaking I don't think you should go work for companies with more that 50 - 100 employees. After that stupidity start showing up way too frequently.

<comment><USER3> Before I started my first job, the summer I left uni, I read the entire archive from 1989 to 2012 and laughed at it.

When my job started a few months later, I was absolutely floored when some of the stuff I saw there played out exactly as the comic.

I quit after 3 months. I could not get a single thing done in less than 3 weeks there.

</comment></comment></comment><comment><USER8> When your co-workers start getting routinely carted out by emergency workers for cardiac distress, seizures, and other problems developed since they started the job. A job can grind you down and I'm watching my current one eat some co-workers alive. There are limits to how much stress you can put a person through routinely.

</comment><comment><USER9> Just switch often until you are sufficiently paid and found one that doesn't suffer from dysfunctions like employee/manager churn. Then use the capital you built up to work less, focusing on other things in life than work. Every time you switch you have to prove yourself again, you'll have to prove you are worthy the perks (working from home etc).

My recipe was switching around and then _back_ to my first employer later in my career. A place I knew had good climate where I could stay 5-10 years with ease.

</comment><comment><USER10> When a company starts focusing the majority of its energy inwards: politics, favoritism, infighting, thinking of how to look good internally, bullshit stats and presentations, you name it - but very little time spend on the customer or the product.

<comment><USER3> One of my reasons for leaving is that I'm watching our internal systems dissolve - some of the stuff I have responsibility for is hosted on rickety old systems that are long due for replacement, but management refuses to spend any money (or allocate time to rebuild them) because they're not customer- facing. Painful underinvestment for political reasons will be the death of this company. The IT team are fighting fires on a daily basis, and a major outage would probably have the 4 of them walking out (yes, 4 people supporting a global company). I've wisely decided to move on before it all melts.

</comment></comment><comment><USER11> When I feel like I can't bring as much to the company as I would like, and either coworkers, managers, company's culture prevents me to so or that I don't feel rewarded for my skills

</comment><comment><USER12> I have a simple rule. If you're already seriously contemplating leaving, then it's time to leave. Because typically, it's only going to get worse from there.

Chris Dixon once posted something along the lines of this: "If you think you're going to fire someone six months from now, you should fire them now."

I believe that if you think things will get worse 6 months from now, then leave now.

<comment><USER13> +1. My father always says "when you're thinking about getting out of the boat, you're already out". Meaning, if you were 'in the boat', you would be thinking of fixing it.

</comment></comment><comment><USER14> I am currently in this situation. The company ran out of money and cant afford to pay us. That is a good indicator to find something else.

<comment><USER15> This is equivalent to looking for the exit when the ceiling has already collapsed.

</comment></comment><comment><USER16> For me these have been the reasons in the past:

\- New job offers me a significant improvement in my standard of living. Twice, it's been the offer to move to a different country. It gives me a chance to experience different places and have better living conditions.

\- I stop learning or feel like I am not adding any more value to my role. I start feeling stagnant and worry about future.

</comment><comment><USER17> If on a Sunday afternoon you get a sinking feeling of despair about having to go to work tomorrow, it's time to leave.

</comment><comment><USER18> I've written a few articles on it.. one included a tyrant boss I had to escape and the other was simply outgrowing your company.

Check those articles out here:

[http://www.confessionsoftheprofessions.com/the- opportunity/](http://www.confessionsoftheprofessions.com/the-opportunity/)

[http://www.confessionsoftheprofessions.com/outgrowing- compan...](http://www.confessionsoftheprofessions.com/outgrowing-company/)

</comment><comment><USER19> When the calendar becomes more important than the quality.

</comment><comment><USER20> 1) When I dont allowed to contribute in innovation or my inputs are being ignore by Manager/Leaders.

2) People leave managers not companies

</comment><comment><USER21> You always keep looking, and when something sufficiently better comes up, you switch.

Get offers in time, so you have some on hand in need.

</comment><comment><USER22> If you find yourself doing maintenance work, move on.

There is nothing wrong with maintenance work, it is valuable and gives the company the ability to service its clients. However, if you are no longer able to improve the process and that is what you were doing before, move along.

Maintenance work is a big signal, don't ignore it.

</comment><comment><USER23> When I see that smarter guys are leaving.

<comment><USER24> As long as you're aware that this may not happen if your org is experiencing Dead Sea Effect. Having just gone through this situation, it can be challenging to understand when you're bitter and when you really are surrounded by less-than-ideal developers. Imposter Syndrome complicates this, as well.

</comment></comment><comment><USER25> I'm reminded of a former co-worker that said he could write down the reasons why he'd eventually leave a job after two months, even if he stayed for years longer. Not always true and sometimes change is forced on us, but a useful insight.

Moving has a cost, in time and effort, and a risk. You can look at the benefits of the new job (and likely downsides!), and weigh them against the current one plus the cost of searching and moving.

</comment><comment><USER26> I just encountered this 2 days ago.

When the company decides to adopt a new (to them) technology stack that is not part of where I see my future self.

<comment> maze-le New tech stacks can be learned. If it fits the development and product, why not? Even if you have a personal dislike for it, you could still learn from it. I find in-fighting, interpersonal quibbles and ridiculing of co-workers far more insufferable.

<comment><USER27> What about moving to old stacks like... PHP?

<comment><USER28> PHP's problem isn't its age, but that it was intended to do a very specific task in a very specific context, and people who came to it later lack a fundamental understanding of this. If, somehow through magic, PHP was invented today, it would still have this problem, which is the root of most of the other problems with PHP.

I only mention this because some "old stacks" are good, in the sense that they are heavily battle tested, and people still use them because they've been successful over a number of years. You have to be able to use your judgement as a professional to determine whether the move to the "old stack" stems from a good reason or not before deciding to jump.

(I personally would jump if I someone said "let's use PHP instead," but I don't think I would be in a job where PHP could be considered an alternative in the first place. Your situation could be different.)

</comment></comment></comment></comment><comment><USER28> If you're having bourbon for breakfast to cope with the current death march, you should have left months ago.

</comment><comment><USER29> When I am bored with what I do. Let me explain a bit more. Currently I work in php but I feel that what I do is not a challenge anymore. I've been doing php for 8 years now and I get the same problems over and over. I want to switch to something that challenges me.

</comment><comment><USER30> When there's not a "project" in sight and I have little control over the direction of my work.

But then I'm a contractor, and I change up to every few months. Or weeks.

</comment><comment><USER31> You have listed the most common reasons in your question (pay hike being the number one reason why people switch jobs and it's a correct reason).

I would add another possible reason. If you get an option to go work to a different country and the company will take care of your visa and offer you attractive relocation package. I think it can often be worth it to gain some international experience. You can always come back in few years.

</comment><comment><USER32> There's one simple rule. When all the executives start reading the same book, and try to get everyone in the company to read that book, run! If they announce the construction of a new HQ, you've already been there way too long.

<comment><USER21> Never work for a Christian (or Muslim etc) company?

</comment></comment><comment><USER33> What I'd like to know is how to decide when to leave/switch careers.

</comment><comment><USER34> When either of these is true, I quit my job:

\- I can't benefit the company I work for anymore,

\- I feel I have stopped learning/advancing in my current position,

\- I have stopped feeling satisfaction from my accomplishments.

</comment><comment><USER35> It's when I feel like I'm standing still. If I don't see how I can progress or improve myself then I have nothing left to gain there.

</comment><comment><USER36> Life stability.

Happiness.

In that order. The balance between these two is something I need to maintain in order for me to say whether or not it's time to switch the job.

Happiness is a lot of things. This is a personal compass. For me it's a combination of doing work that's interesting, working with a company whose mission I believe in personally, while having a good life balance. If I say I'm signing out and saying bye at a particular reasonable time on any regular(!) day, and that's respected, that's good enough for me.

Life stability means do I have the means to support myself and those around me reasonably well. This is actually the primary point Sometimes the jobs that make me happy might not pay me all that great, but if I'm at a point in life where maybe other investments are paying off well, or I just don't need to have that much money, I can take the job. On the other hand I can have a job that pays me lots of money but I'm really really not happy with it. But sometimes it's necessary to suck it up until another opportunity comes to me. I can't just flip the bird to life's responsibilities and quit because I'm not happy. Sure maybe I readjust my needs to make stability to look cheaper, but the point is that all basics MUST be covered at all times.

Real world examples:

Second job of mine. The company vision had changed considerably since I joined it. After a merger it became less about innovation and while I don't say it's bad, I definitely didn't agree with it. At the time it was just my wife and I living in a not so expensive apartment and we had very few other responsibilities. So I quit. Admittedly to a slightly better paying job but the priority at that time was happiness since I had achieves baseline life stability (and a bit more too).

Didn't like the new job at all. Burnt me out and after 6 months I left to a new job. This was paying me less than my second job so quite a dip in earnings at the time. But it was exciting, and I loved so much of it. Again I was just about fine with stability since my wife was also working so the primary balancing factor was happiness.

6 months later though, my wife and I were expecting our son. This flipped the equation completely. My wife really was hoping she could exit the workplace so she could spend time with our baby when he was born and this meant a big change in stability requirements for me. I actually went back to the same business I had my third job with. It was a new product they were building so I expected it to be different this time around. That turned out to be wrong. I won't lie. I hated it. But I sucked it up to the point of near depression. Since the balance was starting to fall out of place, I hunted another job and I hope I've found my perfect place at Buffer. Right now it's everything I could ask for and has all my guiding principles in place.

Hope that lengthy exposition of my career helped out :D

Side note - Leaving the company I worked at twice was a hard one and led to a lot of tension. I felt horrible about bits of it, but I couldn't let my personal mental health deteriorate any further. I regret that I had to put the company through that as it almost felt exploitative (that was never my intention though). We parted on lukewarm terms but now have better relationships which mended slowly (not fully) over time.

<comment><USER37> Buffer seems really nice! I like how transparent they are with salaries and that it's fully remote. What technologies are you guys using?

<comment><USER36> It's a wonderful place really. The people are also really nice and my only wish is that we could meet each other more in real life :D.

As for tech that we are using,

The main app uses php. But lately we've been breaking apart the app into micro services which are a combination of node js, golang, and Python/flask apps. We run it all on kubernetes. Meanwhile the front end has been transitioning towards being more react based :)

<comment><USER37> Nice. I need to find a job like that. I moved out to a new province and accepted the first job I got offered and I didn't like it.

Then I got offered and accepted a new job which seemed nice but it's just so boring.

I need to be more picky seeing how companies like Buffer exist. I always just take the first offer I get because I don't like interviews and I've been lucky enough to get a job offer after the first interview I do when looking, but it's pretty stupid in retrospect. It's a gamble that has long lasting effects.

</comment></comment></comment></comment><comment><USER38> If we collect all the reasons in this thread together it rules out a significant majority of companies. Just saying.

</comment><comment><USER39> TL;DR:

The first few job changes I've made were, in large part, due to two things:

1\. me trying to find a job in NYC that would allow for a seamless transition to TX while preserving my compensation and job responsibilities, and

2\. Finding a job that will accelerate my transition into a senior management or technical sales role.

It took me a few years to find a job that met goal (1) (I'm actually making more now than I did in NYC by a healthy margin), and I have a strong feeling that my current job will really put the gas on goal (2).

Longer:

There were also minor reasons behind me switching roles:

* Job 1 -> Job 2: Lots of micromanaging and process that made it difficult to do real engineering. Job 2 was much more fun and provided free food and a wear-what-you-want policy. Also, $20k pay increase, which was a deciding factor.

* Job 2 -> Job 3: Potential of moving to Houston at Job 3. Job 2 was amazing but I felt like there was no way of growing my career vertically _unless_ I wanted to become a Linux admin (which I, ironically, became anyway, at least of sorts) or quant (a very high bar to hit, at least at the time). $5k pay increase was not a factor.

* Job 3 -> Job 4: No opportunities in Houston outside of tech support with Job 3. Also, Google was Job 4; no way I was turning that down. They also had an office in Austin. $30k salary cut front loaded by a sign-on bonus and RSUs; opportunity to work at Google outweighed this.

* Job 4 -> Job 5: No relo opportunities available on the short-term (and very unlikely long term). The $35,000 pay cut also hurt over time despite sign-on and peer bonuses. I didn't stay long enough to vest my RSUs, which would have made up for most of the loss. Also didn't feel like I fit with the team well. Very different working/communication style that wasn't for me (it felt very isolated). I kind-of like being in a party atmosphere; open space, lots of noise, events all of the time, etc. My team didn't have any of that; very nice, but quiet, bunch of folks. Also didn't like how far I was from the money and how arguably meaningless the work felt, despite the work being really good engineering overall. (Google makes its money on Ads. I was in Corp Eng maintaining non-prod app servers.) I also ALSO didn't like how you effectively HAD to move to Mountain View or stay in NYC to advance (most of the senior folks are in MTV) and how it took many many years to make it into management at a salary that's slightly below market (even though RSU reloads effectively offset that). Also, Job 5 restored most of my lost salary ($30k pay increase, was a deciding factor).

* Job 5 -> Job 6: LOVED that place, but it was time to move to TX (couldn't take NYC anymore) and Job 5 wouldn't allow it despite having a sales office in Austin. (My boss and I tried to make an extended eng team there; CTO wasn't having it. She was nice, though.) ($10k pay cut but slightly over $10k gained from not having to pay income or state/city taxes. It was a minor factor. I would've seen more of that had I not fucked up my withholding that year!)

* Job 6 -> Job 7 (current): Really enjoyed working there too. Learned that I LOVE LOVE LOVE to travel. Wanted more of a sales-like position. Tried really hard to get myself plugged into sales pursuits; I networked with damn nearly every sales person in the US org and offered to effectively be their PowerPoint person lol. Did a lot of blogging and solo pursuits alongside my engineering work. Was VERY vocal about work that me and my teams have accomplished. Getting to where I wanted wasn't happening quickly enough; also, company outlook was shaky. Also turns out that I was dramatically underpaid (despite it being a lateral salary move). $25k pay increase was a factor.

</comment><comment><USER40> When office politics become more important then the product and the customer.

If somebody comes in, lifts his leg to mark territory, you know the territory has just become worthless and its time to move on.

<comment><USER41> It's very hard to avoid in anything but the smallest companies.

<comment><USER40> Its the signal of a dying creature. Once office politics are waged and won, hierarchy's are established- suddenly, communicating ideas openly for people only interested in the product and the customer - and by doing that jumping over hierarchy's is a criminal offense - the last terminal stage is reached.

The duration of the process may vary- the outcome does not.

<comment><USER42> The vast majority of corporate america is a dying creature then.

The problem is that the vast majority of the upstarts who will eat them will also die, -and- even the winners may not usurp anything for 20+ years. At which point they, too, will likely start 'dying'.

I think you exaggerate the diagnosis. As with a patient with a disease, you have to modify treatment. The reality is that learning to deal with office politics is an important skill to have.

It's really easy to say "politics" with a look of scorn on your face...and then turn around and read about 'influencers' and 'how to win friends and influence people' and '7 habits of highly effective people' and etc, and think "oh, hey, figuring out how to learn what people are thinking and appeal to people's needs is super important". They're the same thing.

'Jumping over hierarchy is a criminal offense' \- sometimes yes, sometimes no. The point you miss is that with enough people, hierarchy can be necessary. If you've ever been in a position where you have to make strategic decisions, you -have- to delegate. In fact, many of the things that make me feel good as a developer, such as being empowered to make decisions (beyond just the code, but in terms of features and things), require someone else to trust me to make those decisions (i.e., delegation).

"Well, our whole team makes the decisions"; fine, are there other teams working on other things? Do you all make your own decisions? Because if so, you have delegated responsibilities to those other teams, just as they have with you. If not, then people who are less informed than you are getting a voice, and that's just unnecessary noise.

As soon as delegation occurs, I don't -want- people crossing over unless it's incredibly important. Same situation, of multiple teams; do you want someone on another team coming to you to complain about issues on their team? Of course not; that's for their team to fix. Unless the issue is something so bad it threatens you and your team, you don't want to hear about it.

In a hierarchy, the same thing happens. I delegate to someone and entrust them with seeing it to its success; I do not WANT someone re-burdening me with that problem, -unless- it's vital I be informed, and that person knows I am not being informed.

Yes, this can break. People can start valuing the hierarchy more than what it's attempting to achieve, I grant you. But as often as not what I've seen are people jumping up the hierarchy to complain about things that are not sufficiently urgent. And part of that is perspective; what is going to bother someone higher in the hierarchy is not necessarily what bothers someone lower down. And yes, understanding that, and knowing what to do about it, is "politics", but also, alternatively, it's "empathy and influence".

Or, put another way, what's the difference between 'manipulating' and 'influencing'? That's the difference between 'politics' and 'organizational intellect'. It's trying to achieve one's goals dealing with a single person, vs trying to achieve one's goals while dealing with multiple. Because when dealing with multiple people, there are always politics, and you can't merely throw up your hands and decide to never deal with it. I wish you could, I'm not always good enough to win the battles I need to win...but I recognize that it's not something I can just avoid.

<comment><USER40> Im sure if you are higher up in this Ponzi Scheme you have all the time for a sophisticated justification.

But where i am, we need our attention on problem solving, attention on important (often cross-department) details - we do not have the time and resources for procedure-obsessed bureaucrats, leeching initiative and resources into there little Japanese gardens of power, while the project as a whole suffers- and all that ever returns from your proposed silod departments is excuses, blame-shifting and informal orders to not reveal information to other departments working on the same project.

I understand that this is human nature and it must run its course, because those who could actually fight it - are actually fighting for it. Still, if you are in a company to innovate and push the boundaries of tech (which usually needs short com-paths, teamwork and the ability to bounce ideas informal), this is the end of your path in this company.

Oh, and before you try to wriggle out by pointing at the "innovation" initiatives started by CEOs noticing the absence of exactly this- which becomes just another shiny hot powerpoint potato being pin balled from department to department. No, that is not it.

Finally something positive- sometimes.. power aggregates, and some control freak snatches too much of it, merging departments, and this one guy, running hierarchical amok, breaks the spell for a time. He basically destroys the attempts of the hierarchy to sabotage communication, by directly sampling data and pushing worthwhile endeavors against the resistance of the apparatus.

You should hear middle-management hiss at the employees, after the manager- type (lets call him the boar), just casually talks to the people involved and gets Information and Ideas, that where "NOT-SUPPOSED-TO-BE-COMMUNICATED", enabling work to be done and problems to be solved. Subversion saves the day and nobody admits it.

So here is, though i detest the personality type when in personal contact, a toast to the likes of Steve - who at least get things done after the calcification sets in.

<comment><USER42> I have 5 years as a dev, and two as a lead dev/architect. I am only recently taking on management tasks. My comment is not biased because I am "higher up in this ponzi scheme", it is predicated on -what I have seen-.

You are living in the happy little world I got to live in before my current job (when I was simply a senior dev), where there was enough protection of the dev team that I didn't need to concern myself about the business (beyond the occasional clarification of a story), didn't need to concern myself with departmental and organizational 'politics', and when I saw it I rolled my eyes at it, hated it, decided I'd never deal with that sort of thing, etc.

But even at the dev team level there were 'politics'; technical decisions would oftentimes be made based on who had the most clout. Now, that clout was usually due to, de facto, speaking to what the rest of the team cared about, understood, etc (i.e., technical language and priorities). But once you go inter-disciplinary, that stops being true.

Fundamentally, most people want to succeed, and they recognize that the way to do that is delivering results. Sometimes there are leeches, who learn to abuse the system and take credit while not helping deliver. It's abuses like this that deserve our condemnation. But the fact is that in an organization there are multiple roles, with differing priorities, and differing definitions of 'success', and fundamentally the way you deal with that -requires- a level of empathy and influence. You can decry it all you like, but that's reality, and something you'd benefit from adapting to rather than objecting to. I'd love it if everyone was technical, even those whose roles are solely focused on business direction and strategy. I'd love it if everyone thought like me, prioritized like me, and was completely objective in making decisions. But that's simply not the world we live in, and, I suspect, that would actually lead to a worse outcome (I'm not good at sales, for instance, and I don't have the insight into how best to sell something, even if it's technically superior and the UX is better than any competitors). You don't have to like it (and again, I -don't- like it), but that's the truth.

Please note, I'm not saying that every org is healthy. But I -am- saying that regardless of the health, understanding what people's motivations are, and how best to disseminate, discuss, debate, and prioritize information given the context you're in will help you tremendously.</comment></comment></comment></comment></comment></comment>


Launch HN: Strings – Delegated App Copy Management - <AUTHOR> Hey HN.
Brad and Jasper here from Strings (www.strings.design). Strings is a tool for writers and product teams to search and edit your app's copy without learning how to code. Developers save time not having to edit copy while retaining control over their code. When writers edit copy, Strings automatically generates a pull request for engineering approval in Git.
While working at our prior companies, we always felt it was painful to get a simple copy change done: - A task is created in eg Jira. - A PM then looks at the tasks and prioritizes it. - An engineering lead looks at it and estimates it. - At last, the sprint starts and an engineer picks up the task for the copy edit. She looks at the edit request and maybe jumps into the design tool to look at the screen in question. Then she goes to find the right string file in the right repo and find the correct copy string to edit, copying or retyping the updated content.
A copy change ends up involving many people, handovers, context switches, processes and may take weeks to get to your users. It creates so much organizational waste and friction that many copy improvements die a slow death. Content bugs and typos live on, inconsistency hurts the brand and the user experience suffers as a result.
Having developers changing copy is a terrible use of engineering time.
It's busy work and requires context switches that distracts from harder problems. Strings sits on top of your code repository allowing writers, designers and product managers to browse and edit in-app copy. Its purpose is to remove the friction and handover steps required to edit copy in a controlled environment where developers retain the final approval.
Strings only take a few minutes to set up
Strings doesn't require any complicated implementation. Developers install the Strings GitHub app and link their string files. That's it.
Try it out here and let us know what you think.
Brad & Jasper <comment><USER2> Excellent! From a Project Management perspective, it also reduces overhead having to estimate a task and consider for backlog.

A ticket can be created for copy changes, and then once Devs approve, tickets can be closed.

<comment><AUTHOR> Yes, that's the hope. Fewer handovers and fewer people involved. My experience has been that there is an exponential time factor based on how many people need to touch a given task. Really slows things down especially for larger teams.

</comment></comment><comment><USER3> I've been waiting for something like this - can't wait to try this. How are permissions managed for different levels of users?

<comment><AUTHOR> The permission structure is basic at the moment - the admin can decide who can join. Devs have final approval rights for any edits that make it into the apps. In the future we are planning to build out more permission functionality that supports more complex workflows.

</comment></comment><comment><USER4> This is great! Giving non-coders a clean way to interact with engineers using Github is really useful.

<comment><AUTHOR> Thanks robdmc. That's the idea to empower others to interact with code without having to learn how to code. And takes an annoying tasks off the devs.

</comment></comment><comment><USER5> This is awesome. Have been looking for something to help with this!

<comment><AUTHOR> Thanks Jamie</comment></comment>


John McAfee says he had a 'highly exaggerated' shootout with the police - <AUTHOR> http://www.businessinsider.com/john-mcafee-arrest-driving-under-influence-possession-of-handgun-2015-8

<comment><USER2> John McAfee says a lot of things.</comment>


Coordinated raids of Zwiebelfreunde at various locations in Germany - <AUTHOR> https://blog.torservers.net/20180704/coordinated-raids-of-zwiebelfreunde-at-various-locations-in-germany.html <comment><USER2> For those who can't read German: _Zwiebelfreunde_ means 'onion friends'.

<comment><USER3> Since news coverage suggests questionable work of the police you might be interested as well in the fact, that Germany does not have a construct like "fruit of the poisonous tree".

</comment></comment><comment><USER4> Official update from Chaos Computer Club's blog (in english) -- [https://www.ccc.de/en/updates/2018/hausdurchsuchungen-bei- ve...](https://www.ccc.de/en/updates/2018/hausdurchsuchungen-bei- vereinsvorstanden-der-zwiebelfreunde-und-im-openlab-augsburg)

<comment><USER5> > The mere presence of an e-mail address at a large free provider on a website > has caused law enforcement authorities to deduce that a German association > that helps raise funds for this provider must be connected to this website > somehow. Although Zwiebelfreunde clearly has nothing to do with the > operation of this provider, they were suspected anyway.

This is a strawman or poorly explained. It is not explained to us how law enforcement has connected the onion friends to the mail provider, but that is not proof that law enforcement do not have evidence of such a connection. It is also not clear to us that the onion friends is not connected to the operation of the mail provider. The presence of a bank account in fact suggests otherwise; the funds in the bank account does indeed facilitate the operation of the mail provider.

Can anyone explain better?

<comment><USER6> Oh wait I see where you are going wrong. "The presence of a bank account in fact suggests otherwise; "

Let's switch out the entities and see what you think. An anonymous blog posts terror threats and links an email @gmail.com, the investigators discover that onion friends have a bank account supporting donations to google. So they raid onion friends.... does that seem justified?

<comment><USER5> [https://en.wikipedia.org/wiki/Terrorism_financing#Germany](https://en.wikipedia.org/wiki/Terrorism_financing#Germany)

If the onion friends had a donation page up to support a terrorist group, I think they should be monitored by security police and raided if there was a reason.

Your case when the bank supports google is not a cause since google is not a terrorist organisation.

In this case of the onion friends, the donations seems to have been going to donations to a anonymous mailer web site, and depending on what is done at that web site, raids could be justified or not. I think the "connection" has been established, which CCC would like to say there is none. Yet, in your own example, you seem to admit a connection, just not a cause for a raid.

<comment><USER7> Except the Onion friends do not have a donation page up to support "a terrorist group"... that is stretching things a bit far.</comment></comment></comment></comment></comment>


BigDog robot is back with a new video - <AUTHOR> http://gizmodo.com/372272/video-of-bigdog-beta-quadruped-robot-is-so-stupid-its-hilarious?autoplay=true

<comment><USER2> It took me a moment, but I thought BigDog had traveled even deeper into the uncanny valley before realizing it was two guys in black tights.

</comment><comment><USER3> Amusing but isn't this more suitable for Digg/Reddit?

<comment><USER4> The fact that you even dare ask the question of whether humor belongs here means that your whole post itself must be some kind of elaborate joke, and, as I thought everyone here knew god damned well, humor is not tolerated here! Ban Him.

</comment></comment><comment><USER5> A lesson in marketing. Timely + hilarious.

</comment><comment><USER6> So creepy... So creepy... So creepy...

</comment><comment><AUTHOR> I'm amazed that BigDog is capable of using a swing!

</comment><comment><USER7> ok that made me laugh - kreative :)

</comment><comment><USER8> I love that.</comment>


Led Zeppelin stars face copyright trial for Stairway to Heaven - <AUTHOR> http://www.bbc.co.uk/news/entertainment-arts-36022876 <comment><USER2> Led Zeppelin have ripped off many artists, and Jimmy Page basically admitted it. More here: [http://www.willardswormholes.com/archives/24449](http://www.willardswormholes.com/archives/24449)</comment>


Variable Specific Impulse Magnetoplasma Rocket - <AUTHOR> http://www.adastrarocket.com/VASIMR.html <comment><AUTHOR> More info on these rockets:

[http://www.spectrum.ieee.org/aerospace/space- flight/rockets-...](http://www.spectrum.ieee.org/aerospace/space- flight/rockets-for-the-red-planet)</comment>


Show HN: Hackerwall - View Hacker News in images, on any device - <AUTHOR> http://hackerwall.paracode.com/

<comment><USER2> Awesome!

<comment><AUTHOR> Thanks, hope you find it useful :)</comment></comment>


Text-Only TC - <AUTHOR> https://www.medium.com/@fairpixelsco/redesigning-techcrunch-650a13786d5b <comment> ro-laren I've seen a bunch of these "Text Only [x]" demos and they are all much better than the original site for use on mobile. Perhaps it's time more publishers started simplifying their sites drastically- they could still have ads which might actually be more successful if they load quickly...</comment>


'No code' will define the next generation of software - <AUTHOR> https://techcrunch.com/2020/07/07/no-code-will-define-the-next-generation-of-software/ <comment><USER2> I've been seeing this canard for the last 40 years. When my ghost return in 40 years hence, things will be no different.

It ranks up there with "We will all speak to our computers instead of WIMPing or CLIing them". Yeah, right. There's no way we will speak to our computers until AI has improved to such an extent that the spoken word is truly understood in all of its myriad nuances by a computer. I don't see that happening for at least another hundred years.

</comment><comment><USER3> Again?

Disregard that, but we could really do with "fewest-code-possible" workflow engines with basic actions like modifying a database value or sending a mail on certain triggers. Flow of MS was hinting in that direction but the product got integrated into their BI solution and renamed power automate or something like that. And you have to pay for an action that does a HTTP-request. So I guess this was failure. Many companies might not know it, but are looking for that I think.</comment>


This Is How a Prisoner of War Feels About Torture - <AUTHOR> http://m.theatlantic.com/politics/archive/2014/12/John-Mccain-Speech-Senate-Republican-CIA-Torture-Report/383589/?single_page=true

<comment><USER2> sadly, the generals safe at home think that any prisoner of war should be court martialed because he didn't die trying to accomplish its mission.

see the reception the spy ship captain got when his crew was arrested by north Korea. there were several calls for court martial when they were released.</comment>


Why you should expose your Facebook profile for potential employers - <AUTHOR> http://blog.12spokes.com/running-a-business/hiring/why-you-should-expose-your-facebook-profile-for-potential-employers/

<comment><USER2> This is like saying, I'm an employer and I want you to expose your fb profile to me so I can see the answers to all the questions it is illegal for me to ask you in your interview.

</comment><comment><USER3> facebook == public

Why don't people get this by now?</comment>


Multiple vulnerabilities in Ruby - <AUTHOR> http://www.ruby-lang.org/en/news/2008/08/08/multiple-vulnerabilities-in-ruby/

<comment><USER2> None of these vulnerabilities is particularly scary:

* You were already pretty crazy if you were relying on Ruby "safe levels" to sandbox code, and I haven't seen anybody who does. If an attacker can eval Ruby code in your interp, you lose.

* An algorithmic DDoS against a bad regex is a classy attack against Webrick, but it's not as if once you fix it you're not vulnerable to DoS attacks.

* DL and "taint" don't play well together. You shouldn't have been relying on taint, but pretty much anyone can see that if an attacker can control the arguments to the DL functions, they get to jailbreak from the interp.

* The resolv.rb DNS spoofing problem is the 1995 problem, not this year's problem: monotonically increasing QIDs. The reason nobody noticed it until now is that nobody uses resolv.rb, which is a thread-safe async full-ruby DNS client hiding in the Ruby standard library. They ought to just remove it from the library.

</comment><comment><AUTHOR> It'll be interesting to see if the Ruby core team handles this round of vulnerability patches with more candor than the last.

Judging the amount of detail they've provided on this news post alone I'd say they're off to a better start.

<comment><USER3> Agreed. I'm a big fan of Ruby, but when millions of people are using your product, you need to put some thought into the engineering process behind it, and that includes putting some forethought into how you're going to handle security problems.

Here's to hoping they get it right this time...

<comment><USER4>
      you need to put some thought into the engineering process
      behind it, and that includes putting some forethought into
      how you're going to handle security problems

Again, the ruby-core crew aren't thoughtless, or inexperienced; they have processes in place for both normal releases and security advisories, and have a pretty damn good track record for getting updates into the hands of the folks who need 'em.

There are now far too many versions of Ruby out there in the wild for the core team to effectively predict who is going to be affected by a particular issue. Every Linux distro and release of OS X has a slightly different bundled Ruby runtime, and most people don't seem to bother tracking the stable release from the core team until something like the last round of security updates leaves them scrambling to keep up.

The problem isn't the core team failing to handle security issues, it's the community not giving a shit about the code that makes up the 'ruby' binary until something goes wrong, and then not having any clue how to update their systems and do basic compatibility testing.

<comment><USER3> I stand corrected; I was under the impression that the big problem with the last release, was that it broke core functionality that had been available in all previous stable releases.</comment></comment></comment></comment>


Only 13 arrests in 7 years of SF online auto break-in reports, DA says - <AUTHOR> http://www.sfgate.com/crime/article/Only-13-arrests-in-7-years-of-SF-online-auto-12526601.php <comment><USER2> When I interned in San Francisco in 2012, living on Harrison St between 3rd and 4th streets, the auto break-ins were so bad and happened so regularly that every single Friday and Saturday night if I passed someone getting out of their car as they parked on my street, I'd slow down and try to tell them that every single car on our street would have it's windows broken and anything in sight stolen by the time they got back from the club at 2 or 3. And every Sunday and Monday morning I'd see the piles of broken glass on the street where each car had been parked. I think it would have been better if that broken glass hadn't been swept away, so that people parking there the next week might have noticed and decided to park elsewhere. And multiple times I saw groups of people crying outside of their car after returning to find their purses and laptops stolen, I saw multiple people have their work and lives thrown into chaos. Thesis papers lost or possessions they couldn't afford to replace gone. And yet I never saw a single police officer on my street, ever.

I often thought about how fun it would be to get a paintball gun with a scope and camp out on a roof some night, knowing that there'd be someone who I could reap some karma with.

Oh and we also had a homeless guy who literally slept on our buildings doorstep. So there were mornings where we literally had to step _over_ him to get outside.

May have been a factor in my decision to not move there after graduating.

Now I live in NYC where I can live in a working class neighborhood with project buildings scattered all around Brooklyn, and yet I don't ever notice any auto break-ins. And you see NYPD everywhere.

</comment><comment><USER3> This all stems from the residents themselves. They vote against policing and for people who basically take the view that we should feel bad for the criminals because they have turned to a life of crime. There's only a Rudy Giuliani between here and there but SF will never elect him or her.

</comment><comment><USER4> My car was broken into in SF near a school. The school had a camera pointing at it, and when I asked they said they'll happily share the footage with police.

What did police do? Told me "it was probably a homeless person and the homeless have it bad enough" so they'll do nothing!

<comment><USER5> The homeless in California have it so awful...they can sleep on the fuckin beach almost every night. Sounds better than what I've got cooking.

<comment><USER6> Could you please stop posting unsubstantive comments to Hacker News? We're trying for better here.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

</comment></comment></comment><comment><USER7> If professionals are committing 80% of the crimes, then investigating a few would make a big dent.

<comment><USER8> SFPD can investigate all they want; getting the D.A. to actually prosecute is another story.

<comment><USER9> SFPD and the DA just do not care about car break ins. That despite that auto break ins are the #1 crime issue that people in the city care about.

</comment></comment></comment><comment><USER10> The majority of the people in San Francisco just don't see auto break-ins as a priority. In fact, they sympathize with the people who break into cars, as they seem them as an underclass that is forced to do this to survive.

<comment><USER11> You gotta make that $3,000 rent somehow

</comment></comment><comment><USER12> How hard would it be to plant a car with a camera and mic in it with police in an unmarked van a couple blocks away? It almost seems like they're taking advantage of a lack of police effort in this area.

<comment><USER13> Not only put a plant car out there, but put 20 of them out there with SMS notifications in them when the windows get broken.

Wire camera's all over the thing and call the cops when the window gets broken.

<comment><USER14> Identifying the offenders doesn't matter if you aren't willing to punish them. The voters of SF aren't. A DA who correctly represents the people of SF doesn't go after indigent defendants for minor property crime. A police chief or mayor who shares his constituents' values doesn't spend resources on arresting them.

<comment><USER5> Hundreds of dollars of damage and possibly thousands of dollars in theft is now minor property crime.

Top shelf.

<comment><USER14> Stealing items worth under $950 is petty theft in California.

</comment></comment></comment></comment></comment><comment><USER15> the number of SWAT unit deploys probably exceeds this number by some absurd ratio</comment>


Alfred Workflow for TensorFlow, PyTorch API Docs - <AUTHOR> https://github.com/lsgrep/mldocs <comment><USER2> Hi! Do you want to add it to my new platform for Alfred workflows: [https://www.alfredworkflows.store/](https://www.alfredworkflows.store/)</comment>


Ask HN: What tech stack to choose in my first stint as a freelance developer? - <AUTHOR> I just got my first project as a freelance developer, and I am unable to choose a tech stack. Some background - I've worked with Enterprise Java and C# for a few years now, so I am fairly comfortable with these two languages. But I have never worked with any of the hottest technologies including languages and frameworks like Python/Django, Node, or RoR. I also will need a deployment solution, and I am unable to choose between IaaS like AWS/Azure/GCP or just to go with PaaS like Heroku, since I have never worked with any of them.<p>Should I explore new frameworks in something I know (Spring/Play/DropWizard with Java) or choose to go with something that I haven't worked with in order to learn new tech as I am developing? <comment><USER2> Go with what you know can get the job done. It's fun to use new tech, but Java isn't going anywhere and it's very stable and performant at this point.

Your concerns should be the following:

1 - will this stack get the job done, and at a reasonable velocity

2 - will you lose time because you need to ramp up on a technology you're not familiar with

3 - how maintainable will this be for developers who come after you?

Spend time figuring out what you'll need to accomplish for this project, and then decide which framework will work best for it.

If you're still not sure what to go with, it can be really worthwhile to do a quick proof of concept that covers the areas you feel most uncertain about. I did this before choosing Elixir for a recent project, and it helped me feel a lot more confident in that choice.

Outside of your freelancing, I'd encourage you to spend time using new tools are frameworks. That way, you'll know the strengths and weaknesses of each before you need to pick one for a project.

<comment><USER3> This

</comment></comment><comment><USER4> When I'm looking for a new project, I analyse these 3 aspects: Client, Domain, Tech Stack. My experience taught me that, I can only handle one unknown aspect among these in a project, more becomes a problem sooner or later.

\- If the project is for a new client that I have no connection beforehand, I only work on a problem domain that I'm familiar with, and I use a stack that I'm confident in.

\- If the project is in a domain that I've no experience, but I know the client, I go with the tech stack than I know I can get the job done.

\- If the project is for a client I know, and I have experience with the problem domain, I let myself to choose a new stack to learn if there is one that's suitable for the project.

I'm having great success with this strategy. Obviously these are just general guidelines, and the specifics of the projects can affect my decision, and common sense always applies.

</comment><comment><USER5> Most of this depends on your project's requirements.

PaaS is much simpler for you as a developer, assuming your desired stack is supported. Caveat is it will likely cost your client more. Although, it may not if you account for billable hours saved by not having to deal with IaaS. Depends on the project's scale and resource usage. With a small scale project, PaaS may be a wash or even cost less.

Obviously it's good to expand your horizons learning new technologies. Doing so while under deadlines on someone else's dime, perhaps not as much. It's at least something to consider if there's very lax deadlines. How to bill it ethically is up to you and likely depends on a ton of factors.

Using modern frameworks in languages you already know does seem to be a good compromise. Your learning curve there should be drastically lower than learning an entirely new stack from scratch. This is probably the safest route, and if you choose it I'd suggest learning new stacks on your own time regardless.

</comment><comment><USER6> I'am assuming you are 'just' developing solutions. Your customers are only interested in a product - not tech side.

So, your goal should be: "How I can develop (and maintain) this product in the most efficient way?".

Step 1 : Get stable grounds

Pick a language that can solve most of common challenges that you will tackle. Make yourself proficient in it. You need to minimize time spent on thinking "how I can do it in X language?". (You've got Java/C# skillset so most of your web skills should be around here).

Step 2 : Optimize

You've got another web project? That's great! You just need to pick up template with all boilerplate (like: logging, monitoring, deployment, auth etc.) from last project and fill missing features.

Step 3: Extend

Now, you can finish most of your projects in seconds. It's time to find new clients. Search for new domain - like: mobile, embedded or machine learning. This time you can decide if your existing toolset is enough for new problems or rather, adding new one will be more beneficial to you. Like: You can do a lot of ML stuff in C# but Python is the place where all important stuff happens.

PS:

IaaS vs PaaS

Here is question for you:

Do you like to do more admin stuff for low cost hosting?

Or do you like to focus on coding and spent a bit more money and let cloud do most of admin work for you?

It's a your time vs money optimization.

Personally, for small (scale) project I'am running with IaaS - but I already have knowledge how to do it. For big ones - it's better to stick with PaaS - even very skilled DevOps can't single-handedly deal with big scale.

For you I would advise using PaaS since you don't have experience with neither PaaS nor IaaS. PaaS is a lot easier to learn and you can always migrate your code to IaaS as a Step 2 :)

Good luck and have fun.

</comment><comment><USER7> As a longtime and current asp.net developer I use the Laravel php framework for client work and side projects. Modern php is very easy for a java or c# dev to pick up. Development speed and ease of deployment is what matters and Laravel is a mature batteries included rapid application development framework with a large community and ecosystem and even it's own hosting platform Laravel forge.

<comment><USER3> Yeah, I'm surprised how far modern PHP has come, but I fear that the Laravel is but life support for PHP.

<comment><USER8> There's Symfony and some other good frameworks around. PHP 7 was a god send.

<comment><USER3> People are still using Symfony? I've been told that it's mostly behind the scenes.

<comment><USER8> People use what works for them. Besides it's a great framework and it's stable, great for boring businesses.

</comment></comment></comment></comment></comment><comment><USER9> Use the stack that makes the project as easy, robust and low maintenance as possible taking into account risks involved in anything new you have to learn along the way. Sticking to only what you know can make life harder for yourself as well and means you're not expanding your skills.

If you're highly skilled in Java and C# you're not going to find it challenging to pick up Python or Rails. Heroku is a great choice for a freelancer as well as it's so low maintenance by a large margin in my opinion compared to something like AWS. You certainly want to avoid things as low level as VPSs as well. Personally I think you should take a couple of days to experiment with Heroku so you can see there isn't really that much to it.

</comment><comment><USER10> Depends. If it's a new project, choose the oldest thing that's still widely supported. Often times, this will be something like straight Java or PHP. It's not trendy at all, but it will run under 99% of system configs out there. Also, be sure to document your work as much as possible and give that documentation to whomever you're turning your work over to.

If you're taking over another project, make sure the client has docs before you take it on. Otherwise, there's a good chance that you won't be able to deliver what they want. Best to avoid those customers initially (if you can).

</comment><comment><USER11> If this is your first stint, you've got a lot riding on this reputation-wise. You need to hit every deadline you set, and it needs to work the first time. It would be best to use the most familiar (and yes, boring) stack you can possibly use [1]. The client does not care at all what is under the hood: they care about whether the product does what they want it to do.

[1] [https://news.ycombinator.com/item?id=12788804](https://news.ycombinator.com/item?id=12788804)

</comment><comment><USER12> Learning new tech is good of course but I wouldn't overdo it. It is also important to have some specialization and skills that you focus on.

It also depends on your clients, they will most likely be making the call based on the tech they already are using in their current stack and their tech employees. So when they bring in a consultant they will want to keep in line with their in-house tech stack not to complicate future maintenance and hiring.

</comment><comment><USER13> In my opinion you should know Spring MVC ( or boot ) as a Java freelancer.

I'd also go with Spring because they have a huge market share and many projects require Spring knowledge.

By knowing Spring you are expanding the circle for possible clients.

Play/Dropwizard are nice frameworks but they don't bring you any value as a freelancer because nobody will require knowledge/experience in those frameworks.

</comment><comment><USER14> I would highly recommend jhipster. We used that build our highly scalable website aihello.com

It builds the core of project using spring boot and also generates docker and kubernetes files. Entities are easy to create and the 'business glue' is auto generated.

It even integrates Kafka which allows us to plug-in machine learning framework via Apache spark

Overall very happy with the framework

<comment><USER15> Agreed. Considering Java background, Spring Boot with a little bit of help from JHipster is the most sensible choice.

</comment></comment><comment><USER16> Id check the rates offered and choose the one that pays the most

</comment><comment><USER17> Happiness on F sharp</comment>


I'm in like with you invites - <AUTHOR>

<comment><AUTHOR> I have three... Just post your email address & I'll invite you.

Only catch is that once you get an account, you have to put your invites here as well.

<comment><USER2> joshfraz AT gmail DOT com :) thanks!

</comment></comment><comment><USER3> I've got an account now. Where do I go to invite more people? Do I have to earn invites?

</comment><comment><USER4> I have 3 or so invites left too, if anyone wants some just let me know

<comment><USER5> me.jobs.r.u.woz at gee male dott comm

<comment><USER5> sorry danw, i mistyped earlier with th eunderscores. it's me.jobs.r.u.woz at gee male dott comm

<comment><USER5> Yikes..sorry, didn't realize that you guys were talking about that site! Not my thing. Thx.

</comment></comment></comment></comment><comment><USER6> Jacob dxt lyles a t gee male dxt cxn

replace x with o, and n with m

Thanks!

</comment><comment><USER7> How abt sending one (just one) invite to me at kashif.razzaqui (at) gmail

</comment><comment><USER8> bladerDOGMA at gmail please! (remove the Kevin Smith movie)

<comment><AUTHOR> Ha, I have no idea who Kevin Smith is. I think I was able to figure it out, though...

Remember to invite others on here!

<comment><USER8> Thanks. It looks pretty sweet. I'll start an invite thread as soon as I have some invites. I have to wait to get any right?

</comment></comment></comment><comment><USER9> If anyone has an extra: wotandonato-at-gmail.com Please!

</comment><comment><USER10> niran at niran dot org

Let's hope there are still some invites floating around here.

</comment><comment><USER11> invite me plz. thx in advance! :)

nicholas.s.barnes attttt gmail.com

</comment><comment><USER12> davidLAMP at seenly dott commm (remove the all-uppercase word)

Thanks!

</comment><comment><USER13> nandan.naik att gee malee dott comm, please.

</comment><comment><USER14> yan.sarazin [at] gmail [dot] com

Thanks

</comment><comment><USER15> jeykottalam, gmail

Thanks in advance.

</comment><comment><USER16> tj.mcconnell AT gmail DOT com

Thanks!

</comment><comment><USER17> send invite to email@example.com

<comment><USER18> firstname.lastname@example.com

</comment></comment><comment><USER19> i'm there! yaacovtp at yahoo com

<comment><AUTHOR> Invite sent.

<comment><USER19> They have the social games down pretty well. I'm sure more are coming which should lead to plenty of time spent on the site/mobile per user.

Waiting for my invites and I'll give them out here.

</comment></comment></comment><comment><USER20> udai00 (at) gmail.com thanks.

</comment><comment><USER21> rohun.gholkar at gmail dot com

</comment><comment><USER22> jim ( a t ) runfatboy.net

</comment><comment><USER23> jmak at sbcglobal dot net

</comment><comment><USER24> timg.is.here at gmail.com</comment>


NYC EMTs stop taking cardiac arrest patients to hospitals - <AUTHOR> https://nypost.com/2020/04/02/coronavirus-nyc-emts-stop-taking-cardiac-arrest-patients-to-hospitals/ <comment><USER2> It is unusual to transport a patient to a hospital if return of spontaneous circulation (ROSC) is not achieved in on-scene.

E.g, in San Francisco's protocols, if a patient doesn't regain a pulse after 30 minutes of CPR, the patient is declared dead and not transported to the hospital (unless the base hospital requests transport, which is rare). See policy 4050-II-2 (Medical Indications).

[https://www.sfdph.org/dph/files/EMS/Policy-Protocol- Manuals/...](https://www.sfdph.org/dph/files/EMS/Policy-Protocol-Manuals/EMS- AGENCY-POLICY-MANUAL-030319.pdf)

From that perspective, I'm surprised that the old policy existed. With respect to getting a pulse back, there's not much that can be done in a hospital that can't be done in the field. (Of course, after a pulse returns, then the hospital can do lots of things that can't be done on-scene).

</comment><comment><USER3> My understanding is that if hypothermia isn't involved, anyone who can't be resusitated by paramedics but can be resuscitated at the hospital are very unlikely to have any quality of life afterwards.

This is based on some "real talk" by a YouTube doctor so I'd love anyone more knowledgeable than me to chime in.

<comment><USER4> The chance of dying before discharged from a hospital if you have a heart attack out of a hospital is about 90%... If you need CPR, your chances of going home again are small.

[https://ahainstructornetwork.americanheart.org/AHAECC/CPRAnd...](https://ahainstructornetwork.americanheart.org/AHAECC/CPRAndECC/AboutCPRECC/CPRFactsAndStats/UCM_475748_CPR- Facts-and-Stats.jsp)</comment></comment>


Chrome 9 Sandboxes Flash and Adds WebGL Support - <AUTHOR> http://googlesystem.blogspot.com/2010/12/chrome-9-sandboxes-flash-and-adds-webgl.html

<comment><USER2> I wish Google would push Adobe to give us a flash that performs decently on Linux. The Cr-48 runs absolutely horrible with even basic flash applications.

<comment><USER3> adobe is pushing themselves

[http://blogs.adobe.com/flashplayer/2010/12/flash-player- for-...](http://blogs.adobe.com/flashplayer/2010/12/flash-player-for-chrome- notebooks.html)

</comment></comment><comment><USER4> Yay for WebGL by default, I've been waiting for this for a year. Now I don't have to get my users to install a beta version of a browser.

</comment><comment><USER5> For a company that was legendary for their perpetual "beta" web apps, they sure do increment those release version numbers on their browser awfully quickly.

<comment><USER6> They are just numbers. Here's how it works. The version number is four parts: major.minor.build.patch.

major.minor are used for each significant release and are set for marketing purposes. They are currently on a 12-week release cycle, where major is updated for each cycle.

build.patch are used for engineering purposes. They update the build value daily on trunk. Periodically, they create a release branch from trunk. On release branches, the build portion of the version is fixed and the patch value is incremented daily.

So for example, the upcoming release will be 9.0.597.something. Typically it takes them a couple weeks to get from beta to stable, so I expect 9.0 stable to be something like 9.0.597.33.

But, as I said, they're just numbers. :-)

<comment><USER7> I wonder if they'll slow down on the major version now that they've "caught up" to IE...

<comment><USER8> I can't imagine the branding looks as good for Chrome 23.0 as it does for single digits. Maybe they'll switch to code names.

<comment><USER9> Version numbers aren't very prominent for "regular" users. I don't think they really care about branding or marketing the version.

</comment></comment></comment></comment></comment><comment><USER10> Just tried the Aquarium demo and the system (OS X) became unresponsive…… and just checked CPU/memory usage: CPU utilization < 10% with 1.2G free memory. So it must be the GPU since WebGL is hardware-accelerated???

<comment><USER11> Ubuntu with ATI 4 __* perfect here (Fans on in some seconds BTW)

Did you enable the about:flags options? As it says in the page its beta features, so it wouldnt be strange to behave badly in some ocasions/systems

</comment></comment><comment><USER12> The sandbox is highly annoying. I can't attach files when using flash uploaders. I thought it was just a bug that would go away soon because I'm on the dev channel.</comment>


User generated search engines - <AUTHOR>

Are there any search engines being created that give users the power to vote good sites up and spam sites down? It seems like this would be a way to clear out some of the weak content that bloats up the internet. Thoughts? <comment><USER2> Doesn't google allow this already to some degree?

Perhaps not exactly what you were looking for.. [http://arstechnica.com/web/news/2011/03/1-with-a-bullet- goog...](http://arstechnica.com/web/news/2011/03/1-with-a-bullet-google-lets- the-people-vote-up-search-results.ars)

</comment><comment><USER3> Then spammers would upvote their own sites and outnumber any normal user. And competitors would downvote each other generously.</comment>


Linus's rules on keeping Git history clean (2009) - <AUTHOR> https://firstname.lastname@example.com/msg39091.html <comment><USER2> When I first read the often-repeated advice _NEVER change public history_ or something along those lines I was like 'yeah, 'duh'. My opinion on that changed a bit though and I reckon this advice follows the standard pattern of good guidelines being falsely wrapped as strict rules which must never be broken.

In practice: I only work in smaller teams and we use feature branches which get merged into master after review, having the netto effect pretty much no- one is ever working directly on master. So it if happens someone does something like pushing a commit only to figure out 2 days later it has a typo or even needs a small code change or anything which would improve the commit with trivial changes not really worth creating another commit, we just go ahead and fixup/rebase/force push i.e. rewrite public history. Since the rest of the team always does pull --rebase of master anyway and/or rebases feature branches this is not a problem at all.

<comment><USER3> The question is though, why would you even bother changing public history, even if you can work around the practical problems?

In my view, the concept of a commit mapping exactly to a functional change, and therefore being able to be correct or incorrect, improved, etc, is going against the grain of what revision control is. A commit just is what it is. If it contains a typo, a bug, etc, you notice and fix it 2 days later and that's another commit. Git just describes what happens. What is the utility in pretending that didn't happen and rewriting the history of changes as if you never made that mistake? Who benefits?

If you are concerned about keeping master 'stable' so that checking out any commit will result in a clean, working codebase, you can use abstractions on top such as tags to point out to people which commits are good and/or bad.

I get the idea of a stable, neat git history as though you were all knowing and perfect is comforting, but it's also nonsense and trying to attain that is just wasted effort. Just let git describe what actually happened, yes it's chaotic, yes there is constant rapid iteration, mistakes made and corrected etc, but that's just the process of building stuff. That's the reason you shouldn't rewrite history. There are pragmatic exceptions, though, like writing out egregious errors like committing security keys that can't be quickly changed.

<comment><USER4> I'm convinced that the obsession with rewriting history is solely due to inadequate tools. Git doesnt keep the name of a branch after it's merged, so people want to make merges look like a single commit on top so that they don't face this ambiguity. Github doesnt even display the branching structure in its commit log, which also shows a woefully small number of commits per page, further incentivising squashing/editing. Many tools (some are better than others) display commit history in a similarly non-dense way or in a way that implicitly discourages branching in some way, e.g. gitk doesn't even display commits from other branches by default. Large numbers of commits are also unwieldy when commits are hashes that cannot be ordered mentally just by looking at them.

Over in mercurial land people are more likely to keep history, even though history rewriting is not only equally powerful, but more safe than git via the 'evolve' extension. We can limit our bisecting to a single branch, such as a stable branch or the default (mercurial parlance for 'master') branch, skipping over commits in feature branches that have been merged in. We can do this because the branches retain their identities post-merge. The most widely- used tool, tortoisehg, displays large numbers of commits densely, with the full tree structure and branch names on display by default. Commits can be referred to via their hash or by a simple incrementing integer (which is only valid on your local clone, but still, this makes things easier for local work).

So we keep all those typo commits - they're usually in feature branches anyway since we don't merge until features are done and we try to keep the default branch functioning. If a merge breaks something, we bisect on the default branch only, which will tell us which merge commit broke it.

I'm still sad that git won the VCS wars over mercurial.

<comment><USER5> > I'm convinced that the obsession with rewriting history is solely due to > inadequate tools.

The article at the top literally said explicitly never rewrite public history, so what obsession are you talking about exactly? Git has what you want as long as you don't mistake local operations before push as "history", and instead only consider history to be commits that have been shared with other people. That makes more sense anyway, there's nothing sacred to preserve in the arbitrary, noisy sequence of things I did while I was bumbling around on my machine _before_ I push.

Git was designed with a toolset that shows every commit and lets you clean up your own work before you contribute it to public history. Its tools work well when you understand git's design and use it the way it was intended. Git is not Mercurial, though, that's true. Perforce isn't Mercurial either.

Git can limit bisect to a single branch, and normally does skip branches until you want to descend into them. Don't confuse losing the branch name with losing the branch, git doesn't lose the branches, only the names, and only if you delete the names.

<comment><USER4> I'm talking about attitudes in general and not disagreeing with the post.

I agree with the advice never to rewrite public history, and I totally agree with Linus's approach. He is in the minority with this attitude though, since never rewriting public history means never doing a squash merge and never rebasing a merge/pull request at merge time (both of which are common practice). I suspect even people who endorse the idea of never rewriting public history kind of don't think of the fork from which a pull request is coming as 'public' even if it literally is.

I love the kernel's "keep-all" approach and want more people to use it, I bet if they did the tools would improve to actually work better with that style - whereas right now I think the tools are driving the workflow instead.

<comment><USER5> > right now I think the tools are driving the workflow instead.

Okay that's fair, I think that's true. To some degree it has to be true to matter which tools you use, right? Even if it's Mercurial.

I haven't personally seen squash merges and rebasing pull requests being used on pull requests of large multi-person branches very commonly, are you saying that's common? I agree that there's common practice of using squash merges and rebasing on private branches, or branches that contain commits by only a single person and contain only code commits.

I'm looking for clarity, not disagreeing with you. The 'principled' argument for never using rebase is almost always attacking the branching practices of individuals and not teams. There definitely is a fuzzy line between pushing to your own branch that is visible to others, but nobody else touches. I'd normally consider that case private, not public, even if it's "literally" public.

I don't feel like I'm hearing what the tangible advantages of never modifying history are. Why is history considered more sacred than clarity of semantic intent? People make mistakes and noise, a _lot_ , why shouldn't the tooling allowing fixing mistakes and cleaning up irrelevant noise after the fact, as long as it doesn't affect others?

Edit: I'm realizing another conceptual line to draw beyond what makes history "public": the question is one of whether you're going to rewrite history out from underneath other people. If not, and you're the only person affected, then you made the local history in the first place, there's no principled reason to prevent you from updating your own work, because it's equivalent to making the same change before committing. If your rewrite is modifying commits that other people already have, then you're inflicting damage on other people. You may cause them to have merge conflicts, you may be modifying code dependencies they're working on but haven't pushed, it's bad for very practical reasons. Using this lens of what other people depend on, does that help clarify your examples of squash merges and rebased pull requests?

<comment><USER6> > I haven't personally seen squash merges and rebasing pull requests being > used on pull requests of large multi-person branches very commonly, are you > saying that's common?

I have. Github makes it quite easy to fall into this.

> Why is history considered more sacred than clarity of semantic intent? > People make mistakes and noise, a lot, why shouldn't the tooling allowing > fixing mistakes and cleaning up irrelevant noise after the fact, as long as > it doesn't affect others?

I've got a concrete example of where it causes problems: code reviews. If you've reviewed a branch at a specific commit, and standard practice is to squash merge into master, or to otherwise allow rebases after the review point, you lose the confidence that what's on master is actually what was reviewed. I've seen cases where people got into the habit of getting reviews done, then doing a squash rebase _locally_ , and including tidy-up commits which had never been seen by anyone else before merging straight into master.

If you're in an environment where the rule is that Everything Must Be Reviewed, that's a problem: it's far too easy for an accidental bug to end up on master despite the code reviews and the automated tests on the preceding branch being green.

With the example above, I never would have seen the problem unless I'd been trying to use the git history to measure some statistics about how long it was taking us to get code reviews done. It was only because I was looking at the history commit by commit that it jumped out.

<comment><USER5> That's a good example, IMO, and yeah it should be very much frowned on (or outright disallowed) to modify an approved code review before pushing without further review. That is kind-of a code review workflow problem, more than a discussion of whether rebase should "never" be used though, right?

The company I work for now has both notifications for commits in code reviews, so everyone sees if you modify something after it being approved, and some repos also have lockdown features where the approved review is tagged and cannot be checked in if modified. So this can be solved with some tooling around code reviews, and git itself doesn't exactly add up to a modern code review toolset. This may be as much or more of a Github problem than a git problem... acknowledging that there's a large swath of developers that doesn't really know the difference between them.

<comment><USER6> It's a bit of both. If you don't have a strong "thou shalt not rebase" culture, it can be difficult to get people to accept the inconvenience of getting re-reviews on the branch they've just committed a typo-fix to, so you end up leaning on more complex tooling to force the issue.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> My work flow consists in working in some topic locally and committing in the smallest topic units possible. Then as I make some fixes due to typos or plain wrong logic I just amend or fix up. The longer I keep branched out then bigger the likelihood of having a lot of fixup commits. Then I use this awesome magic git rebase somehash^ -i --autoquash. It re orders all my fixups automatically so it is very painless to consolidate everything before pushing. Maybe it is very known but this fixup/autosquash thing changed my productivity a lot.

<comment><USER8> I don't think this feature is very well-known, in fact I've seen it mentioned before, thought "how useful! I will absorb this into my brain now" – and promptly forgot about it.

I think there is a critical mass of advanced git features required to be really fluent in git, and there is a sizeable fraction of everyday git users who simply haven't made it all the way there yet. Some teams have at least one person who has enough git features under their belt...

To recognize when merge conflicts are being haphazardly made unnecessarily, to be really particular about the shape of the git commit history and be aware of what merges can make those conflicts, to occasionally show the rest of the team some of these tricks or bail someone out when things go haywire, but at least in my experience spreading all of this knowledge to the rest of the team is a long slow process.

</comment></comment><comment><USER9> If you want clean git history, you must burn "git merge".

No commit should ever have more than one parent.

<comment><USER10> That might be clean, but it's not history.

</comment></comment><comment><USER11> I'm not very experienced with git. I use `git rebase` to pull changes from a remote into my private repo in order to prepare pushing my changes. My understanding of rebase is that it takes a commit history with one parent and replays them all onto a different parent. So I don't understand how rebasing would destroy history. Could someone explain what the issue is?

</comment><comment><USER12> In my opinion source control history is much overrated. Instead of documenting your diffs, you should just document the code itself.

Every developer has some limited time budget for writing documentation. If you spend lots of time and frustration trying to get the git history correct, you have less time left over for actual code documentation.

> See? All the rules really are pretty simple.

Hmmmm.

<comment><USER13> I'm guessing you've never had to find the source of a bug via git bisect.

</comment></comment><comment><USER14> 'Commit to master, that way merging is somebody elses problem'

</comment><comment><USER15> I bet a lot of people will find this advice completely confusing. Emailing a patch?

<comment><USER16> Even if not many developers use an email-based workflow for their own work, I think it's pretty well-known that the Linux kernel does.

<comment><USER17> I suspect you're overestimating the number of developers who know or use Linux. Many developers use Git on Windows and don't know anything about Linux, let alone about the workflow of the kernel team.

<comment><USER18> The git project uses the same workflow for development that the Linux kernel does. That is, using a mailing list to submit and discuss commits before merging them into the maintainer's repository.

<comment><USER17> Sure. But many users of git don't know (or care) about the workflow of the git team. They know github. Maybe gitlab. Or bitbucket. They could go their entire development careers without ever sending a patch as an email, instead relying on feature branches and pull requests.

This could be completely alien to them, and it seems wrong to downvote srg for pointing that out.

</comment></comment></comment></comment></comment><comment><USER19> Is this all about making it possible to do delta debugging with git commits?

</comment><comment><USER20> Please add (2009) next time.

</comment><comment><USER21> Isn't that obvious? How else could it be?

<comment><USER22> Look at the cpython history. There is a major change from Mercurial to Git. It's not that Mercurial doesn't support the "rebase" workflow. It does discourage it though. Personally, I much prefer the "rebase your WIP changes, avoid merges" style. It is much easier to work with the resulting history.

<comment><USER23> I never got this argument. What the point of "clean history"? History is for log of work, not for being nice read.

<comment><USER24> "Commits ordered by when I figured out a bug" has a lot less value than "Commits where changes are grouped by semantic logic".

Stuff like git rebase don't work so well if you have a bunch of WIP busted commits as well.

Maybe you don't commit that often, but people I work with (and myself) commit pretty often so it's easy to have just outright mistaken git commit messages like "fix X" followed by "actually fix X". going through a rebase to have "fix X" mean "fix X" will be great for the future debugging session with a git blame.

<comment><USER25> On the other hand, "fix x" followed by a couple lines of rationale, then "actually fix x" with a discussion of why the previous fix was wrong is more useful to someone trying to understand x.

<comment><USER26> I think the discussion is valuable. I think adding those insights to a wiki 'Pitfalls' page or whatever is valuable.

From the top of my head, the cases where I'm looking at Git logs are:

1\. Code Review. Most of the time I'm reviewing code is looking at a diff. But obviously one of "fix" and "actually fix" is redundant. A clean history also benefits if I want to focus in on one of the commits.

2\. Annotation/Blame. If I'm debugging through some issue and looking at older changes, it's nice if coupled changes are in the same commit.

A warts-and-all history has some advantages over rewriting git history (e.g. you could find patterns of where "actually fix" happens and try and improve those), but rewriting history makes the log a better communication tool.

</comment></comment></comment></comment></comment></comment><comment><USER27> If you're working with a group of people you should never git pull prior to a commit and always git push -f

<comment><USER28> Joking aside, "git pull -r" is pure magic in the face of upstream rewrites. It always does the right thing:

[https://mergebase.com/doing-git-wrong/2018/03/07/fun-with- gi...](https://mergebase.com/doing-git-wrong/2018/03/07/fun-with-git-pull- rebase/)

After I wrote that blog post someone told me the reason for the magic is the use of "git merge-base --fork-point" under the hood.

<comment><USER8> `pull --rebase` is nothing, go back and read the history of `rebase --preserve-merges` and now `rebase --rebase-merges`

I have worked with both, and the new one is much better. Of course this only matters if the branch you are rebasing has merges in it (so in all likelihood, you must be a release manager to need features like this)

Between rebase-merges and --onto, I don't spend hardly any time fixing up bad merges anymore.</comment></comment></comment>


Where did white keyboards go? - <AUTHOR> I have noticed a new trend of black keyboards about a decade ago. It was weird and I didn't care for it. But now, I am having big troubles finding white keyboards in general. Usually it is less than 10% of the offering in majority of stores.<p>So it makes me wonder, why is this happening? I believe that black keyboards are ergonomically bad from the contrast point of view so I am having hard time accepting this as a reasoning.<p>(and the lack of iso 105 layout keyboards is also an interesting topic for another day) <comment><USER2> I think it is because they look old school and filthy. The former is the reason why I buy them, the latter is why I have to wash them more frequently than black keyboards.

<comment><USER3> How do you wash your keyboards?

<comment><USER2> Mostly it is just the caps that get filthy, so I remove them and let them soak for a few hours under room temperature water with some dishwasher liquid. A few swipes with a cloth does it for the base.

If I need to clean the insides, I use some canned air spray.

</comment></comment></comment><comment><USER4> That was the old beige computer aesthetic, it went out with the iMac.

As long as you can get a white/gray Topre Realforce, it doesn't really matter.

</comment><comment><USER5> [https://www.amazon.com/s?k=white+keyboard&crid=DF1J05HVR9EV&...](https://www.amazon.com/s?k=white+keyboard&crid=DF1J05HVR9EV&sprefix=white+keybo%2Caps%2C336&ref=nb_sb_ss_i_1_11)

</comment><comment><USER6> Behind the beige.

</comment><comment><USER7> Macintosh</comment>


Heapsort, Quicksort, and Entropy - <AUTHOR> http://users.aims.ac.za/~mackay/sorting/sorting.html

<comment><USER2> Definately one of my all time favorites. Mackay's book also contains a brilliant solution to the weighing problem due to Conway, where you label the 12 spheres and the sequence of weighings is always the same (meaning that the spheres you choose to weigh on the second or third weighing don't depend on the outcome of any previous weighing. After three weighings, the outcomes of the weighings identifies the odd ball and whether it is heavier or lighter by a lookup table, which is cleverly constructed through a symmetry argument. It completely blew my mind.

<comment><USER3> It's on torrent, thank FSM. I'm reading it right now, it seems well written.

</comment></comment><comment><USER4> Wow, this is brilliant. Well-written analysis and explanation on how Quicksort and Heap sort differ, and ideas on how they might be improved. Understandable to mortals, no less!</comment>


Ask HN: Registrar with highly technical staff - <AUTHOR> I have been with one of the oldest registrars for a couple decades that is now basically just a help desk.  I have tried a few US registrars and I am finding the same pattern.  Fancy UI, limited DNS functionality and maybe one or two semi technical people buried deep under call centers.  I just use registrars to point to my name servers.  If there was a way I could edit the root servers directly, I would.  Thus far I have tried name.com, network solutions (now web.com), namecheap, godaddy.  I heard mixed reviews of Gandhi but have not tried them yet.<p>I am looking for a few registrars that are "engineers for engineers", if such a thing exists.  Are there perhaps any EU based registrars that maybe I have not heard of that have a highly technical staff? <comment><USER2> DNSimple offers a fantastic service provided by a highly technical team.

I have no affiliation with them other than being a happy customer.</comment>


Ask HN: Python Development Environment - <AUTHOR>

I have been programming in python for a few months now in a simple text based interpretor. I want to move to a more robust development environment. The first one that came up in my search is Eclipse.<p>I am looking for something with module and library management, code auto correction, debugging tools,; moving toward continuous deployment and automated build testing. Any recommendations/reviews from the HN network? <comment><USER3> I've had the full komodo IDE environment for a few years, for a while somebody else paid the $$ for the license. It's nice if you do the full suite of languages targeted: ruby, python, JS, CSS.

<http://www.activestate.com/komodo/>

The other non-cheap IDE specifically targeting python is wingware, I've heard good things but never used

<http://www.wingware.com/>

\</comment><comment></comment><comment>-

I also played with the vim plugins and textmate bundles for ruby and python (at least a year ago) and thought they werre well done, quite usable. I'm one of those people who thinks you should learn vi/vim cause it'll be installed on platforms / servers where you don't have root access.

<comment><USER4> Komodo has been more than acceptable for me for a couple of years now... but I have to admit it doesn't feel quite complete for me. I can't pinpoint what's missing though.

I recently tried Netbeans for some PHP development, and I think it's ok - <USER2> yes, it really slows down when it's "scanning projects...". (I've configured to sync to server on save) - how annoying.

Recently had to learn more vim and I don't mind using it on the server (console environment), but prefer an actual UI.

</comment></comment><comment><USER5> I would say eclipse with pydev. I tried out komodo for a while but it seemed a bit on the slow side. Same story with netbeans. I also recently tried out wingIDE but was not too impressed. Most of my coding in python is done in either textmate for oneoffs, vim on a server for quick fixes or eclipse/pydev for more in depth stuff.

Pydev has the code completion and debugging facilities that you are looking for and I would imagine that you could find a suitable plugin to do the continuous deployment and automated build testing as eclipse has a strong plugin ecosystem.

</comment><comment><USER6> If you want to go the Eclipse-Road Aptana is worth a look.

I personally would recommend Emacs + bpython/ipython. A deadly combination.

</comment><comment><USER7> Unix. Use multiple refined tools that operate well together.

Editing: vim or emacs. if vim: nerdtree, vim-snipmate, vim-omnicomplete, vim's python integration.

Deployment: rsync (or your DVCS). I have a simple script that 'touch'es my Django .wsgi files before rsyncing to the deployment server.

ipython is great.

</comment><comment><USER8> I have been using Stan's Python Editor (SPE) for quite some time and am very happy with it. Easy to install on my Ubuntu box, no big application+kitchen sink package, no magic customization files and free to boot.

</comment><comment><USER9> intellij or eclipse.

Intellij has a free trial for 30 days, that way you can see if going for 'closed source' vs open source is worth it.</comment>


What Is the Easiest Language to Learn? - <AUTHOR> http://twoweeklinguist.com/easiest-language-to-learn/

<comment><USER2> clickbait title, tldr - it depends</comment>


239 Experts with 1 Big Claim: The Coronavirus Is Airborne - <AUTHOR> https://www.nytimes.com/2020/07/04/health/239-experts-with-1-big-claim-the-coronavirus-is-airborne.html <comment><USER2> I really don't want to go back to the office. This week will be a tough conversation with my manager about WFH until there's a vaccine.</comment>


Ask HN: Facebook Connect and Twitter Auth enough for Web App? - <AUTHOR>

I am working on a Web App which is good without requiring any user to register/login. However, the user might need to save some of the settings which might only be provided by Login. Just want to know if providing with Facebook and Twitter IDs to login will cover 100% of the users. Is there anyone here who don't use any of these service? <comment><USER2> I don't.</comment>


Why Your Grandfather Was Much More Ready To Build A Successful Startup Than You! - <AUTHOR> http://inc42.com/entrepreneurship/grandfather-successful-startup/ <comment><USER2> Local sweet store, as it was mentioned in the article, is nowhere near the term "startup". It's just a local business. It's hard to call a newly opened small shop a "startup".

Startup has to grow very quickly and the grandfather didn't have opportunity to make his business grow so fast.</comment>


Why the Concept of 'Evil' Is a Bad Idea - <AUTHOR> https://thoughtcatalog.com/jim-goad/2018/01/why-the-concept-of-evil-is-a-bad-idea/ <comment><USER2> Sheltered intellectual: "Evil doesn't exists"

Rich entrepreneur: "Money doesn't buy happiness"

Fashion model: "Love is about the person not the body"</comment>


The Mathematics of Gamification - <AUTHOR> http://engineering.foursquare.com/2014/01/03/the-mathematics-of-gamification/

<comment><USER2> As always when it comes to data-driven decision, the math seems scary, but is actually straight forward: the conclusion that the score should go through a logistic formula is actually a direct consequence of the innocuous decision to take a specific likelihood form.

Similarly, the key aspect is over-looked: 'honeypots'? What do you mean by that? Are SuperUsers aware of what constitutes a non-acceptable points? Are edge-cases justified and explained? Most places I see exist but their structure is ambivalent: train stations that have two terminals, several restaurants, a corresponding metro station… Should each platform have its point?

The gym I go to recently opened; they have a large swimming section, with two pools (actually five, but the extra three are smaller), changing rooms each with a sauna, etc.: Where can I find a clear explanation of how to describe the place, add venues? Consistent purpose? So, one unit for the whole? 'Any place big enough so that if you are looking for a friend, you'll be able to notice him there?' In that case, the bar is separated by a glass wall from the lower pool, so those should be together, far from the lower-deck weightroom. Same for the nearby re-opened hotel who added a spa, a restaurant, a nightclub, a bar… What I see when checking in are seemingly inconsistent structures, and no explanation how to edit them properly.

Far more than the fairly straightforward 'good behaviour' possible rules (which have little actual impact), clarifying the goal of the tool would help other understand how to implement 'gamification'. See Wikipedia for a stricking case of that.

</comment><comment><USER3> Maybe I'm missing something, but it seems like they are just applying a simple Bayesian model to classify change requests? That doesn't seem to have much to do with gamification. Can anyone explain what I'm missing?

</comment><comment><AUTHOR> Clearly that venue data is valuable to them. Guaranteeing 99% accuracy can be a crucial selling point for 3rd parties. With a subscription-based offering, that data can provide a significant revenue stream.</comment>