What a Senior Staff Software Engineer Does - <AUTHOR> https://medium.com/box-tech-blog/what-a-senior-staff-software-engineer-actually-does-f3fc140d5f33 <comment><USER2> Working for mostly smaller companies, titles haven't really meant anything. My influence came mostly from using the other two levers in the organization - building relationships and building a reputation.

I have a lot more influence over the technical/infrastructure direction of the company I work for now as "just" a senior developer than I ever had at my last company where I was officially the Dev lead with dotted line reports.

There to get anything done I had to go through layers of red tape. Where I am now, I'll use my own discretion on whether I should let the manager know or do everything in the Dev AWS Account (or create another account), do a proof of concept and let them know. Most of the time I either get the okay or a few tweaks or suggested.

And before I get the replies from the infrastructure gatekeepers. Yes, I'm qualified to make infrastructure decisions and I've been browbeaten enough across three jobs to know about compliance issues (HIPAA in our case) inside and out.

<comment><USER3> The compliance seems to rely on you not making mistakes or taking malicious actions, which doesn't really qualify as compliance IMO.

<comment><USER2> Compliance involves encryption at rest and in transit and with cloud providers making sure you only use HIPAA compliant services, getting BSA's with external contractors, minimizing who is allowed access to data, etc.

It's more complicated than this but this is a good overview.

[https://www.hipaajournal.com/hipaa-compliance- checklist/](https://www.hipaajournal.com/hipaa-compliance-checklist/)

</comment></comment></comment><comment><USER4> I find it interesting that a culture is being described here where Senior Engineers are considered lower level, with multiple higher levels above that. It just goes to show that titles mean different things at different companies, and you cannot generalize across this industry. I've had the "Staff Software Engineer" title once in my career. It was at IBM, in the 90s, where it was a was a title given to anyone who was not junior. I had it in my first ever coding role, while I was still learning to code. How the title changed from meaning "Generic Staff Member" in the 90s to "Above Senior" today, I have no idea.

In any case, the job described does mesh well with what I see most "Senior Engineers" doing. So the article in general is a good idea of where long-term growth as an engineer will take you.

<comment><USER5> I think it became widespread because Google named their levels that way. Not sure of the origin of the title at Google though.

<comment><USER6> Google probably got the terminology from Bell Labs. A "Member of Technical Staff" was for PHDs or very accomplished engineers. See [https://www.quora.com/When-did-Bell-Labs-add-the- Distinguish...](https://www.quora.com/When-did-Bell-Labs-add-the- Distinguished-Member-of-Technical-Staff-title)

</comment></comment></comment><comment><USER7> I'm sure this just suits some people's fancy but the idea of being in a "track" is so off putting and mind numbing to me. Ooh here is where I'll be exactly in 5, 10, 15 years. So exciting /s. So glad I went self employed almost a decade ago.

<comment><USER8> It's more exciting if I'm making $300k google salaries at the end of the track.

A track with 6-7 difficult rungs and +10% pay increase? nah, I'm good.

<comment><USER9> I mean, once you hit a certain salary more money doesn't even appreciably increase your quality of life. And I think most good software engineers are already close to that asymptote

<comment><USER10> In the US maybe, but definitely not in most of Europe. Software engineers are not as valued here as they are in some parts of the US (SF bay area, Seattle, etc.). As a result, salaries here are pretty miserable.

I'm a very senior developer in my 30s who lives in Sweden. I have a "good salary" (make the same or more than every other dev that I know in my age bracket), which translates to a take-home pay of around 45k USD.

Sure, health care is free, education is free (no college fund for my kids) and employer-paid-for pension plans are quite decent, but housing is not cheap (450k USD for a simple 4 bed room family home, luckily I don't live in Stockholm where that costs an additional 200-300k USD) and we also pay 25% VAT on almost everything.

30 days paid vacation (not PTO) per year is pretty sweet and so is the lack of overtime (40 hours is 40 hours) and the parental leave (at home with your kids for a year as a father? no problem!). But man, these salaries that I see quoted here on HN regularly (200-300k) do sting a bit...

<comment><USER11> The grass is always greener. Earning those salaries usually means you're in the bay area, where the median home price is 1.5m USD and you most definitely won't get that 4th bedroom.

</comment></comment></comment></comment></comment><comment><USER12> I read the article once and thought, "So at Box a senior staff SWE is differentiated from a senior SWE by mentoring others, and in so doing, has a greater impact. And senior staff is still in the technical track, not the management track. What does the author (or, What do HN commentators) think are the differences between mentoring and managing? Other than the obvious of course."

I read it again--I liked the article--and saw that the article talks about too many kinds of staff-level contributions, including kinds of mentorship, for my question to be relevant.

I'm still interested enough to pose: I had thought elevation of the technical track to "equal" the management track was a response to technical employees "needing" to go-into-management-and-deal-with-people in order to advance their careers. So now it would seem to me that the technical track is absorbing some of the functions of the management track. That's assuming that mentoring is related to managing.

<comment><USER13> All of these level requirements are tacked on by the HR department because they are required for advancement in non-technical roles. Unfortunately they really foul up personal dynamics as some people believe they need to 'mentor' their colleagues in order to fulfill the responsibilities of their job title... how fucking condescending is that?

<comment><USER14> This seems like a really uncharitable view of mentorship.

I have never felt condescended to when I was being mentored by someone with more skills or experience in any of my jobs, and I certainly hope that the people I help through one on ones, code review, and pairing now don't feel as though there's any condescension in it. I think mostly, we all just want to become as good as we can be at our jobs.

<comment><USER13> If everyone wants to become as good as they can at their jobs then why call out mentoring as a special activity? People should already be helping their colleagues perform better at their jobs without incentivizing it as a checkbox for career advancement.

<comment><USER15> This sounds like an argument against rubrics or ladder requirements in general, not a particular problem with mentorship as a requirement.

If you want employees to mentor others, call it out as a thing to encourage. If you don't do that, people will be less inclined to do it, instead focusing on raw technical impact or whatever.

Why call out writing good code as a requirement for advancement if everyone should do it anyway? Well, not everyone values the same things. Making values explicit isn't bad.

</comment></comment></comment></comment></comment><comment><USER16> Are the tracks actually parallel?

Had she gone into management after 5 years, how would the compensation, promotion opportunities, or job opportunities have differed?

I see many people go into management because they think it's the only way to continue to grow a career.

<comment><USER17> They're parallel in theory and get paid the same, but if you look at the ratio of high-level managers to high level ICs, climbing the management ladder is clearly easier.

<comment><USER18> I'm not sure it would be easier for me.

</comment></comment></comment><comment><USER19> The follow-up blog she linked at the bottom is even better at describing the mindset of a technical leader, which will take you far in any organization no matter what your current title is.

</comment><comment><USER20> The main supplier in the area I am working is a huge US company with many different divisions, including a software engineering one. I am working with more a couple of dozens people that have "Senior", "Staff", "Principal" and "Engineer" words in the title, in combinations of 2 or 3 of these words, but it totally makes no sense to me if I am looking at the expertise, effectiveness of their work and the influence/decision power they have: they are all skilled workers with fancy but meaningless titles.

</comment><comment><USER21> Call me unambitious but I think I'd rather just write some code every day.

<comment><USER22> Yes, well, at some point you get tired of seeing people make the same mistakes over and over. Those people might be senior engineers tasked with architectural design for the first time. Those people might be management with their heads up their....um, with misguided ideas.

So the Senior Staff position may involve less day-to-day coding/design, but a lot more heading off disaster, which I would argue adds huge value to the company, and personally I find satisfying. In fact, there is nothing _less_ satisfying than failing to head off a disaster that you could see coming from miles away.

I remember a very senior IC at one company I worked at, named Gary. Gary basically wandered from meeting-to-meeting, only attending a few minutes because his calendar was routinely triple-booked. He would listen to a few minutes of argumentation, ask the one question that would slice the problem open like a sharp machete to a coconut, and then move on to the next meeting. Didn't design much any more, but his contributions had huge leverage.

Don't write off that some day you may want to be a Gary. It may come naturally at some point, when you frequently start thinking: "I've seen this movie before and it has a baaaad ending."

<comment><USER23> The hard part of being gary is being ignored even when you know it's a bad idea.</comment></comment></comment>


How much does it cost to outsource iPhone/android app development? - <AUTHOR> Currently have a few ideas for mobile apps that I'd love to develop. But if the cost is not too prohibitive, I'd like to outsource it.I searched the web for info on good iPhone/android dev shops and prices, but couldn't get good answers, so I thought I'd ask HN. Nothing too complicated. It is just a basic MVP app to test out the market. Am I looking at $5,000, $10,000, $20,000, more? <comment><USER2> There's no real answer to this question without detailed specs. Even then you would only get a rough estimate.

But Let's say you got a very inexpensive developer say $50/hr for 3 months at 40 hours/week that's 480 hr so it's $24,000 for the 3 months. 3 months would get you a very simple app which would serve as an MVP. At best you can use it to get investors to continue with the development.

Putting together an app is expensive and setting up the business to go with it is even more expensive. Good luck!

</comment><comment><USER3> Can't answer that without knowing the scope. One data point is that back in 2010 I built a few very very small self-contained games for people for like 15k-20k. No networking or anything at all. Just simple stuff folks had mostly already done and ad-network integration. These usually took about 3-4 weeks.

If iOS contractors in the states charged less than $200 an hour these days I'd be surprised.</comment>


Why Are Wages Low in Developing Countries? - <AUTHOR> http://mises.org/story/3218#

<comment><USER2> Except to the extent they're artificially depressed by some interference in market pricing (e.g. by politicians or cartels), it can only be because the people are unproductive and/or it's hard to ship stuff to buyers.

<comment><USER3> Are Engineers in India "unproductive" or is it hard to "ship stuff to buyers"?

Doesn't seem like it to me.

So how in the _terms of this article_ can one explain that engineers in India are cheaper than in developed countries?

<comment><USER2> They're unproductive. For example, engineers in India (as opposed to Indian engineers) have made approximately zero of the top web startups.

<comment><USER4> Zoho? Not sure if it is a "top web app" ...

<comment><USER2> "Zoho is an Office Productivity Suite from AdventNet Inc. Founded in 1996, AdventNet is headquartered in Pleasanton, CA with offices in North America, Europe and Asia."

<http://www.linkedin.com/companies/zoho></comment></comment></comment></comment></comment>


PHP is Amazing - <AUTHOR> http://www.forouzani.com/php-is-amazing.html

<comment><USER2> Already existing libraries can hurt development. You can liken it to Jeff Atwood saying "Regular Expressions: Now You Have Two Problems". Not only do you have to write your code, but now you have to understand that library and how to use it.

Just because their is a library doesn't mean there are any consequences that come with using it. There will come a point where the limit of the library has been reached and you must either A.) contribute to it or B.) if things are proper fucked and you end up writing a custom library

Either way making the argument that development is easier because of all the libraries available is like saying, constructing houses is easier because of all the blueprints available. (contrived examples always win)

PHP is a fine language along with Ruby, Python, and Javascript. Each have their strengths and weaknesses. No sole language will win all the time.

references: [http://www.codinghorror.com/blog/2008/06/regular- expressions...](http://www.codinghorror.com/blog/2008/06/regular-expressions- now-you-have-two-problems.html)

</comment><comment><USER3> Broken deployment being easy is not a feature.

Heh, battle tested.

You don't need thousands of developers, just a few good ones. You'll find that for pretty much any popular language.

And open source libraries? Really? Someone here is overlooking the sizable ruby gems and PyPI, and the gigantic CPAN.

</comment><comment><USER4> It'd be interesting to start a company that wrote software in two different languages at the same time. Have a bunch of programmers that don't know PHP or Ruby develop the same features in both languages. It'd be interesting to see how easy or hard they found each language to be and why.

<comment><USER5> Sounds like a poor strategy for a company.

</comment></comment><comment><USER6> It's interesting that the author uses the term "easy" to describe PHP, as there have been a few talks in the Clojure community about the difference between something being simple and something being easy, and the former tends to be recommended over the latter.

</comment><comment><USER7> If you ship that easy, then you may not be able to grow easily in a structured and sane way.

This is true of any language/framework, however. Others encourage better structure and methodology.

</comment><comment><USER8> Really curious what people get out of bashing a language they don't like. I'm no psychologist but I'm sure it's common behavior outside of programming and typically deals with ego.

<comment><USER6> It's not necessarily ego; I'd say it's more that a lot of programmers hate bad design (real or perceived), even if it doesn't directly affect them. The same desire that drives a person to want to do a good job also contributes to them being annoyed by shoddy jobs done by other people.

<comment><USER8> Perhaps. In reading all of these that's never the vibe I've gotten. It's always been one of superiority or arrogance which is why I thought it might be tied to ego. Oh well, we may never know :).

</comment></comment></comment><comment><USER5> > There seems to be a lot of negative commentary directed at PHP recently

If by recently you mean the last 15 years.</comment>


Ask HN: Coworker works to unhealthy exhaustion. Should I say anything? - <AUTHOR>

I'm really worried about his health. On one hand he's an adult and I feel he should be able to take care of himself, but he has a history of depression and pushing himself too hard (and feinting from exhaustion). He works 80+ hours a week to keep up with his work, often works all night and the entire next day, and doesn't tell anyone because he doesn't want to get fired for appearing to be slow at his job. Even at 80+ hour weeks he's still behind. He's just not a very fast worker.
I feel like maybe I should mention something to his manager. I would feel super shitty if he winds up in the hospital because he pushed too much and I said nothing. On the other hand, he's an adult and it seems sort of shitty to talk to his manager about it.
Any opinions? <comment><USER2> Don't tell your manager or HR. If your true motivation is concern for his health, you're unlikely to change his behavior that way.

If you really want to help him, you first need to talk to him about it. Tell him you've noticed how hard he's working, and you'd like to help if you can. Be clear that you don't mean you're going to help by doing his work for him. Rather, you'd like to listen to his side of the story and see if the two of you could brainstorm some solutions.

After you've done this, you may discover that some additional learning/training could help him move faster. That's a best-case scenario. Perhaps he's just not equipped for this job, and he could start job hunting while he's still employed with your firm.

You're more likely to notice some things that can't just be fixed. You may discover that anxiety or excessive attention to detail (perfectionism) are causing him to take much longer.

Those are issues that only he can work on, and he'd need to work on them only with psychiatric professionals.

No matter the size of your company, you're going to encounter people who can't do their jobs very well and are harming themselves and/or the company. It's really none of your business unless A) they're in danger, B) they're doing something illegal, or C) you're their superior. Be very certain that your coworker is in danger before you proceed.

<comment><AUTHOR> >excessive attention to detail (perfectionism) are causing him to take much longer.

He has self professed OCD and says this is often why he takes so long. I do offer a lot help in his work but being somewhat new myself I am not always able to tell him how the systems here work.

I'm not trying to change behavior by telling manager, but more trying to have the manager pay attention to the hours he's working and maybe set an upper limit and make him go home after? I don't think his manager wants him hospitalized or burning out any more than I do.

I have suggested searching for other jobs but I think a combination of depression and helplessness prevents him from doing this. He has really low self esteem.

<comment><USER3> You could try a cognitive argument; beyond a certain number of hours/day, productivity/day starts to dive because you make more mistakes when you're tired and work at a slower pace overall. Failing that, try encouraging him to visit a therapist/psychiatrist. Maybe you could look into whether your company's health plan covers that sort of thing, often they do.

I feel your frustration. It's not really your problem, and it's irresponsible of his manager to let him wear himself down this way. His 'OCD' tendencies might well be an asset in the right context, like doing code review or QA or something instead of building code that's possibly meant to have a relatively short operating life.

<comment><USER2> I'm assuming that by "OCD tendencies", you do not mean a literal, clinical case of OCD. However, I think OP is describing OCD, the illness, not run-of- the-mill conscientiousness.

Despite the way it seems, OCD is not a rational illness, nor does it make you "better" at anything. It's purely emotional, and you can't reason with it. The sufferer feels a huge amount of fear/anxiety related to issues that seem insignificant to a typical person, and they can't choose which issues they are.

In fact, telling him that he makes more mistakes when he's more tired may give him greater anxiety, which would feed the vicious cycle of "doing more work to make sure I didn't screw up" that's going on in his mind.

<comment><USER3> I qualified it because I can't really tell from the limited information the OP gave, is all; that's why I made a point of suggesting professional help. I have relatives with fairly severe OCD and have autistic spectrum disorders myself, but I'm also aware that self-professed medical conditions don't always line up with the DSM definitions so I take them with a pinch of salt.

</comment></comment></comment></comment></comment><comment><USER4> You could offer to sit with him while he works through a similar problem to you, to see where he wastes time, creates work for himself or duplicates tasks. You can then be the voice telling him when to move on.

It sounds like he would benefit from a closer inspection of his working practises. Perhaps he needs to be managed in a different way. For example same amount of work just delivered as smaller tasks with shorter deadlines to avoid overwhelm. Maybe to start with, instead of him being part of an hourly weekly meeting, maybe he needs a 10 minute chat per day to help him to catch up, prioritise and plan the next day. This obviously would be the responsibility of his manager to take on.

Perhaps some training in planning out his working day in advance would throw out some interesting changes in how he learns to manage his own time.

I think the worst thing that could be done is to restrict his working hours which would add an extra level of worry - so he is sitting at home more stressed than if he was working.

The most important thing is to help him catch up so he is then receptive to support helping him keep on track.

</comment><comment><USER5> You might want to suggest to him that he'd probably be more productive if he got a reasonable amount of sleep. Once you're that tired, it's hard to concentrate and you end up making more mistakes, which you then need to spend time debugging or completely re-doing. Fatigue also makes learning new things more difficult.

Also, is he really that much farther "behind" than his co-workers, or is he just "behind" based on some arbitrary and unrealistic deadline set by management?

And I agree with the other commenter who said that you shouldn't talk to this guy's manager. There are just too many ways that could end badly.

<comment><AUTHOR> He's given what is in my opinion a very reasonable work load. I say that because I have the same job and work on the same sorts of projects.</comment></comment>


The biggest threat to Silicon Valley isn't what you think it is - <AUTHOR> http://www.businessinsider.com/sc/flood-threat-to-silicon-valley-2015-10 <comment><USER2> Note that this is an infomercial for "Our Bay on the Brink"... and who the underlying funders are.</comment>


Labor Department Sues Peter Thiel's Startup for Anti-Asian Bias - <AUTHOR> http://www.nbcnews.com/feature/nbc-out/labor-department-sues-peter-thiel-s-startup-anti-asian-bias-n656016 <comment><USER2> This is BS. He's being sued because he's a vocal supporter of Donald Trump. Let's just be honest.</comment>


Deno Is a Browser for Code - <AUTHOR> https://kitsonkelly.com/posts/deno-is-a-browser-for-code/ <comment><USER3> Just for the kicks, I tried using deno for a task at my day job.

We had a need to extract records from a database into a textual format to be processed by other tools later. This is the typical task for a throwaway script which can be written in basically any scripting language. There is nothing in the task that called out for deno but I wanted to try it out and so I did.

I basically worked on the script iteratively, doing small changes, running it, checking the output, fixing things and running again. No bundler, no complex NPM tasks. Just a simple spaghetti JS and a single binary engine to run it. It was a very refreshing experience. Using URL imports was pretty nice, I really like working like that since my preferred JS environment is not NodeJS but the browser. I can see myself transitioning all those small tools and throwaway scripts I'd do in NodeJS to Deno.

People relying on NodeJS for servers and tooling for their client-side webapps might need to wait a bit longer, but for doing small tasks and scripts, I think it is quite ready and better than NodeJS IMHO. These are also good projects to give you a feel for the new runtime.

<comment><USER4> For small scripts there are many languages out there which are better, with a proper standard library and pre-installed runtimes in virtually every machine.

Why would someone want to use a new language and a new runtime in production scripts is beyond my understanding.

Just write Python for those. Even Perl, awk or sh would be better options, and that is saying something...

<comment><USER5> Well I can think of few. For one, if you are writing a script with external dependencies, it's more work than deno to distribute them.

For python, you would need pip. Can you install any script from arbitrary urls using pip?

I am not sure but I don't think you can. You also have to declare your deps for pip to figure out.

With deno, it's just deno run -A url to script since dependencies are declared in the code with their respective url or file location.

<comment><USER4> The whole point of Python is that _you don 't need external dependencies_ for "small tasks and scripts".

A production "script" requiring downloads of third-party code from external servers is already a red flag, by the way.

<comment><USER6> One could extend that logic to argue that all package managers are red flags: after all, you're downloading third-party code from external servers; you just happen to be doing it ahead of time, rather than at runtime.

In principle, there's no reason why the same supply-chain security mitigations npm and other package managers / repositories have put in place could not also be applied in this case: you just apply them at download time, same as before, except now it might result in a runtime error instead of an npm install failure. (No idea if deno does this in its current state, tbh.)

Agree, however, that blindly executing third-party code without somehow vetting it is a security risk.

Also, re: Python - there's a reason why libraries like requests exist; while the Python Standard Library is pretty comprehensive, the APIs it exposes are not always the most intuitive. You might be surprised at how often people pull in helper libraries to work around some of its warts - now, one could argue that maybe they shouldn't do that and should just know the built-in modules better, just as one could argue that functionality is useless unless combined with usability.

<comment><USER4> Package managers are not red flags, the packages, its vendors and procedures behind those are.

When you download a software update for your kernel you are trusting the Linux Foundation and your upstream vendor. They are supposed to have proper processes in place, they sign the binaries and may even have a support contract with you.

When you put a random URL as a dependency, you are just trusting some random person over the Internet not to screw it up.

Re: Python libraries. The topic of this thread was about "small scripts and tasks". The point of Python and its "batteries included" is that you don't need external libraries to accomplish common tasks. It is a mistake to use external helper libraries in your scripts (not _apps_ ).

</comment></comment></comment></comment></comment></comment><comment><USER7> Its very interesting to me the level of skepticism that is being shown towards Deno.

Whether or not you agree with the approach, you have to agree with the underlying problems that Deno is trying to solve. Furthermore I agree with the article in that there is a paradigm shift here, which should be given a chance.

I for one am happy about the url imports for a variety of reasons, but top on my list is that it will (in theory) reduce the total amount of code people are using from other sources, and (in theory) will make developers more aware of what they do choose to import. All of this should reduce bloat and award open source maintainers that solve novel problems in a clear & concise way.

<comment><USER8> There are better ways to reduce bloat. Gitlab can do web asset analysis and throw warning signs when your JS file goes over a certain size. Of course, in server-side applications the use-case would be different, but the idea remains the same: do not depend on developers doing the right thing every single day, depend on an automated system if something like this is crucial to you.

The URL import completely throws away all the goodies that great package managers have. Being able to manage sub-dependency versions is a big one. I do not understand how people are OK with throwing those away. Either they have never encountered issues that stem from dependencies or they just don't care.

Deno could technically add layers on top that make dependency management easier, but then we are back to NPM.

</comment></comment><comment><USER9> The key paragraph:

> The Deno CLI works like a browser, but for code. You import a URL in the > code and Deno will go and fetch that code and cache it locally, just like a > browser. Also, like a browser, your code runs in a sandbox, which has zero > trust of the code you are running, irrespective of the source. You, the > person invoking the code, get to tell that code what it can and can't do, > externally. Also, like a browser, code can ask you permission to do things, > which you can choose to grant or deny.

The big problem with Deno is that permissions, once granted, apply to _every_ imported URL. You cannot ask it to let one script access the file system, another access network and the rest of them run fully sandboxed. This makes it so that you either only import scripts you already fully trust (making the permission system useless) or don't allow any access (making the ecosystem useless).

<comment><USER10> > ask it to let one script access the file system, another access network and > the rest of them run fully sandboxed.

this is actually quite a difficult problem to solve. You're balancing the security needs with usability.

Browsers have an advantage on this aspect, because they can make the assumption that the webpage does not require filesystem access.

i think fully sandboxed OS-esque security model is the only way this can work. Like on android, where each app sees only their own filesystem, and app-to-app interaction is done via a permission based system that the user has to approve.

<comment><USER11> On android the apps has access to shared folders. For example my music player can scan and read files under /mnt/sdcard/Android/data/com.dropbox.android/files/

It maybe more isolated if it follows the nix file system model?

</comment></comment></comment><comment><USER12> To the people who are skeptical of Deno, I would urge you to have patience and try it out. Deno is a young tool and it will take time to develop the features that you take for granted in other systems. But Deno gets a lot of things right. I already love using it day to day.

I remember using Node when it was this age and thinking it was the future, too. And it was. But as with Deno now, there were problems. In fact, Node was far worse in many ways. npm was extremely unstable back then, for example, which often made it impossible to use. Deno doesn't have that problem. Node had to create libraries from scratch and invent a ton of non-standard things along the way to do it. Deno is built on web standards but can also leverage many of the existing Node libraries by using std/node (the Node compatibility layer) or with jspm.io, for example. Yes, there's the occasional quirk or missing library, but it's already easy to be productive with Deno and it's a lot of fun.

<comment><USER13> > _Node had to create libraries from scratch and invent a ton of non-standard > things along the way to do it. Deno is built on web standards but can also > leverage many of the existing Node libraries by using std /node (the Node > compatibility layer) or with jspm.io, for example_

Node.js is based on CommonJS [1] which defines the require() semantics for CommonJS/node.js modules as well as core libs/APIs such as JSGI (for express.js or node core http middleware) and others. When node.js was new, there were many JavaScript app server projects such as helma, v8cgi/TeaJS, and others, and CommonJS was very much a community effort.

[1]: [http://wiki.commonjs.org/wiki/CommonJS](http://wiki.commonjs.org/wiki/CommonJS)

<comment><USER14> The inability to import (requires) modules using relative paths drove me nuts while using nodejs. I hope deno fixes that.

</comment></comment></comment><comment><USER15> I think this is a good article, and worth the time to give it a read. When Deno was first announced I was not sold on this aspect of the system.

Over time though, and after having wrote a barely-above-trivial app in Deno. I've started to come to the conclusion that Deno's form of dependency management is a fresh perspective which ties closer to how browsers work and is a welcome simplification. The article covers a few ways that you can get production/reproducible builds out of the box which is usually people's first worry.

<comment><USER7> agreed

</comment></comment><comment><USER16> Odd that the article doesn't mention Go. Deno works like Go. It's slightly different in that Go added a system for version rewrites recently ("modules"), but other than that it's the same, and if importmaps ever happen, it will be the exact same.

Also Deno has a command line fallback for its version of GOPATH, which is smart because it turns out a huge percentage of devs don't know what env vars are or how to set them.

But other than cosmetic differences, it's pretty much identical to Go.

<comment><USER17> I've been skimming the arguments so I might have missed something big, but isn't the key distinction that Deno can take anything from a URL? Go's "go get" is backed by version control systems, but you could freely point your deno at "[http://dangerous.com/evil.ts"](http://dangerous.com/evil.ts"). I thought the concern was about the potentially problematic flexibility.

<comment><USER18> Isn't that the advantage though, that you can do exactly that without concern.

> deno run --allow-write=~/only-evil-here > [http://dangerous.com/evil.ts](http://dangerous.com/evil.ts)

</comment></comment></comment><comment><USER19> You hardcode the dependency version in the actual URL string in JavaScript code? How in the world is that manageable? I run `npm update` once a week and it brings down a dozen or so updates (occasionally `npm outdated` as well with manual testing).

I bet we'll have a bunch of competing standards for "dependency management" in deno coming online really soon, because there's an obvious need for that.

Also, are dynamic dependencies a thing? Can I run some code to decide (at runtime) whether I import this.package or that.package? Holy hell... with test coverage the way it is in most projects, that's going to blow up really fast.

<comment><USER20> > You hardcode the dependency version in the actual URL

Websites have been doing this for .. 20 years?

It's quite a different paradigm, yes.

<comment><USER21> _Websites have been doing this for .. 20 years?_

Web developers have been trying to move away from that paradigm in order to make sites faster, more reliable, and smaller for almost as long.

<comment><USER22> Web developers have been trying to move away from URLs that describe their content for 20 years?

Well that certainly explains the state of the 'modern' web

<comment><USER21> _Web developers have been trying to move away from URLs that describe their content for 20 years?_

My comment wasn't about URLs describing their content, but rather the assumption that goes along with it that every network request will always work perfectly. Once you realise that things do actually fail occasionally you should realise that local caches and bundling things in to a smaller number of requests can improve resilience.

That's not really an issue with Deno because it does things to mitigate the issue (eg caching packages locally), but _websites_ that loaded libraries using separate requests for each one were horribly prone to failure if one thing was missing, and slower overall if the browser couldn't fetch everything in parallel, so devs invented things like bundlers to fix the problem. Then came things like code-splitting and tree-shaking to reduce the size.

</comment></comment></comment></comment></comment><comment><USER23> If they wanted to fix something on dependency management, they could have started by adding a way to sign the code/packages. Indeed browsers don't allow to sign pages, which means anyone from the hosting provider to the CDN to the mitm corporate proxy can inject any code they want. It sucks and I'm not sure why "Deno is a browser for code" seems to be a good thing....

Hopefully something like google signed http exchange will fix that in the future for browsers at least.

<comment><USER24> Unless I'm missing what you're referring to, that's not true at all - HTTPS is secure and uses certificates to sign and encrypt traffic.

<comment><USER8> I think OP is arguing:

\- Host can change what is in a package at any time. In case Deno calculates a hash on your machine (e.g. package-lock.json), it's not as bad, but still without a signed package you can't be sure that it was the author that released the code in the first place.

\- Host <-> CDN usually happens over HTTP. Often it is the CDN where HTTPS is terminated. Technically the CDN can deliver whatever code to you.

\- Corporate HTTPS proxies exist. With a proxy like this, it can also replace the code with whatever it likes.

<comment><USER25> > In case Deno calculates a hash on your machine (e.g. package-lock.json), > it's not as bad, but still without a signed package you can't be sure that > it was the author that released the code in the first place.

If you trust the URL is in a (sub)domain controlled by the author and it's a HTTPS URL, that's as much guarantee as a signature.

</comment></comment></comment></comment><comment><USER26> The two most frequent arguments against using URLs instead of npm packages seem to be: 1) Security: What if someone changes the code behind a URL? 2) Hard-coded versions in application code

I don't think these arguments are valid. For 1) you can always limit the URLs you use to hosts like jsDelivr or unpkg and reference npm packages directly. In this case instead of trusting only npm to send you the code you requested, you're now trusting the CDN as well. Potentially even better could be to import scripts from Github directly. For 2) a simple solution could be to have a deps.ts file for your project where you import from single-version URLs and export the dependency version-unaware. Now your versions are not scattered throughout your application code.

To me URLs seem like a nice (because compact and universal) interface for dependencies which allows decoupling your package management from your runtime.

<comment><USER4> So, in order to solve 1) and 2), we should return to what every other language does? That sounds like a design mistake...

What do you mean by "URLs are compact"? How can a URL be compact compared to the same URL in some sort of dependencies file? Unless you use the dependency once, of course, which is rare.

URLs and explicit versions in the import also encourage you to use several versions of the same dependency in your code, which is a very bad idea.

NPM's model of referencing packages from central repositories is bad for many reasons proven over the years. But referencing GitHub scripts and arbitrary URLs is even worse.

<comment><USER26> URLs are compact as in a single string they specify everything you need to locate and use the dependency and you don't need any context, like a specific dependency manager (incl some sort of dependency file). I guess I mean compact as in self-contained, not necessarily short.

<comment><USER4> That's fair and I'd agree it could be a useful property for scripts and even small apps if all code was trusted and all networks had perfectly availability.

Sadly, that is not the case, which is why I don't see the advantage of going "the browser way" for local scripts.

</comment></comment></comment></comment><comment><USER27> The first time I dealt with dependencies written directly in code was with Groovy.

It wasn't a good idea back then, it wasn't a good idea in Go and it isn't definitly a good idea in Deno.

<comment><USER28> Care to explain why?

<comment><USER27> Because it ties the source code to the origin of the dependencies, forces code rewrites that don't scale across all dependencies and aren't enterprise friendly for using internal IT vetoed repositories.

Just because a dependency changed location I should not be obliged to touch a single character of the source code.

<comment><USER25> In the case of Groovy that OP mentioned, that's wrong. This is what it looks like in Groovy[1]:

@Grab(group='org.springframework', module='spring-orm', version='3.2.5.RELEASE') import org.springframework.jdbc.core.JdbcTemplate

This provides the dependency's coordinates... but not where it comes from.

You can define where it comes from by configuring Repositories (normally done by modifying the M2 settings file). This is how Java has always done it in Maven and Gradle, even Ant long time ago. And this works really well! Never seen anyone complaining about how that works.

[1] [http://docs.groovy- lang.org/latest/html/documentation/grape....](http://docs.groovy- lang.org/latest/html/documentation/grape.html)

<comment><USER27> I am the OP and you forgot this little detail,

        @GrabResolver(name='restlet', root='http://maven.restlet.org/')

<comment><USER25> No I didn't. This is if you WANT TO use a particular repo. Read the docs and you'll understand that.

<comment><USER27> Which breaks the script when that repo is no longer available.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> The holy grail of package management is absence of packages and versions, but distribution via signature-addressable code.

In the end it's all just functions that take arguments and return values. They should be the minimal unit of distribution. Potentially even with precompiled bytecode signed by some trusted compilation provider.

<comment><USER30> Sounds like you want Unison: [https://www.unisonweb.org/docs/tour/](https://www.unisonweb.org/docs/tour/)

<comment><USER31> I was just racking my memory and searching through my library of interesting links to find exactly this! Paul Chiusano gave a nice introductory talk at strangeloop last year: [https://www.youtube.com/watch?v=gCWtkvDQ2ZI](https://www.youtube.com/watch?v=gCWtkvDQ2ZI)

</comment></comment></comment><comment><USER32> The node_modules folder with its tenths of thousands of files is killing my ssd!

as it is present in every node project I have, and consumes a gigantic number of io operations.

Thus I'm very glad that deno didn't continue this tradition.

<comment><USER33> Replace 'node_modules' with 'deno cache' and presto! you're in the future.

<comment><USER34> Yarn already removes the need for node_modules without requiring to change interpreter and APIs, though.

</comment></comment></comment><comment><USER35> All these "features" of Deno are super cool, but why reimplement a runtime from scratch :(

Can we not benefit in Node from what I essentially see as "package.json not mandatory" \- which I think is already achievable with ES Modules - <USER2> "better permissions model"?

Maybe this can be seen as the effort from several years ago where a project "io.js" branched out of Node as trying to implement certain things the community didn't like. Then after a few years they were implemented into Node and io.js "died off". Although io.js had always the intent of being compatible with Node, so that definitely changes things.

<comment><USER36> Some of what Deno does can be done in Node or people are trying to implement it (I've seen some proofs of concept around the way modules are included). However, it seems that being able to write the runtime in Rust has been a big deal here as it dramatically changes how the runtime is distributed and the developer experience of writing extensions for it versus Node.

<comment><USER35> How is choosing between Rust and C++ as the language in which the thing is written in, an important thing to the users who only care about the JS/TS interface?

<comment><USER37> Because, in the long run, rust is a much better language for writing this in, and will enable faster addition of features _for_ the JS/TS interface and more certainty that the security level stuff is actually secure.

</comment></comment></comment></comment><comment><USER38> The npm registry is like a rickety bridge across a chasm. Every day I cross that bridge because of how much time and work it saves me, but I am well aware that the bridge might fall, especially with Microsoft now in charge.

Claiming that I don't need a bridge does not help me. Claiming that Deno is agnostic about bridges is fine. If someone is looking for a startup idea, here is a perfect opportunity to build a better bridge - one that works with Deno.

</comment><comment><USER39> _For example[https://deno.land/x/](https://deno.land/x/) is effectively nothing but a URL redirect server, where it rewrites URLs to include a git commit-ish reference in the redirected URL. So [https://firstname.lastname@example.com/mod.ts](https://email@example.com/mod.ts) becomes [https://raw.githubusercontent.com/oakserver/oak/v4.0.0/mod.t...](https://raw.githubusercontent.com/oakserver/oak/v4.0.0/mod.ts), which GitHub serves up a nice versioned module._

Thus [http://deno.land/x/](http://deno.land/x/) is the de facto central registry. I'm yet to see how it makes a difference whether the logic of resolving a package name to a concrete version of the package is baked into command line tooling or a web service.

</comment><comment><USER40> Seems odd that they don't support an equivalent of the integrity attribute.

</comment><comment><USER41> Feel like it would've been useful to require a manifest.json or some such that spec'd required permissions right next to the deno package on the FS, in the web server web root. This is not different from manifests for Web Extensions. Then anyone could write their own CLI to download and cache packages but have their own "excluded permissions" list that throws/rejects packages that overreach or could potentially overreach.

Now package writers have a feedback metric for getting as granular as possible with that access their package needs. Even better, anyone could build server infrastructure that does not the client-side validation bit _for_ package consumers with their own attendant CLI tool.

It looks to me Deno opens the possibility of _multiple_ NPMs, which is a good thing over the de facto monopoly NPM exerts today.

</comment><comment><USER23> The issue I have with Deno is not only comparing to NodeJS. If you might use Deno it means you are open to switching platform and even language of you were not going TS already. And if you are at this point, you might as well choose any plateforms, for example one that use a better (with stronger types) programming language and a bigger ecosystem (scala, swift, rust, F#, java, ocaml, kotlin... At this point I feel nearly any other languages fit this description ^^). I have been doing Typescript for a while now, it's probably as good as it could be doing what it does (being a JS add on), but if you don't have this constraint, there are many better options.

<comment><USER42> Please,

scala could be so different that you can spent years learning it and still don't understand a lot of things. Swift is ok, but ARC is a nightmare. Good for mobile though. Rust is really for C++ guys for specific use cases. F#/Ocaml is cool languages, but good luck hiring fast if you need to. Kotlin probably best, but in fact it works with decent performance only on JVM. Native is still 15x times slower than JS.

TS is a first class language and have bigger ecosystem anyway than, say, F#. etc etc

<comment><USER43> I'm going to skip over the other stuff, but

> Native is still 15x times slower than JS.

Surely you meant the other way around?

<comment><USER44> [https://discuss.kotlinlang.org/t/kotlin-native- performance/1...](https://discuss.kotlinlang.org/t/kotlin-native- performance/17823)

Seems Kotlin native can be 100x slower than its JVM version. It's still under development so this can of course change.

</comment></comment></comment></comment><comment><USER45> This may be inviting downvotes, but I still don't understand the use-case of Deno. Why would I use this over something like Python?

In Python, I find I can do most things I want with the standard library plus a handful of well-known packages, so even just downloading the tarballs and installing manually isn't all that onerous.

Why do I want a "browser for code"?

I may just be out-of-touch, as a purely backend/machine-learning/quality engineer. Clearly, this is a real need in the front-end / JavaScript space, but coming from the outside I just don't quite understand yet the value proposition here. Can anyone explain?

<comment><USER46> >Why would I use this over something like Python?

That's more a js vs python question than a Deno question so I don't think you'll find many answers here as we'd veer off-topic.

>I find I can do most things I want with the standard library

A standard library exists for Deno as well. Code from any URL is not an argument against having a standard library. The distinction being made is whether or not package management should be brittle and baked into the programming model to accept only one source of truth vs. any. Any source of truth has the advantage of letting better solutions evolve and reveal themselves over time, which is great for longevity, standards, etc. etc.

> Why do I want a "browser for code"?

My understanding is that this a lot to do with reproducing how front-end code behave "in the wild." If you have a full browser, you aren't tricking your programming model into thinking it's being run in a browser. I think this has tooling advantages in the short term (i.e. simplicity) and more subtle ones in the long term.

<comment><USER45> Thanks. My question really wasn't focused well, and it was easily read not as "please help me understand" but as "hurr durr Python is better".

I think my reaction comes from the dissonance between people saying "Deno is the best thing ever for CLI apps!" then following up with "Here are the ways it's better than Node!", without acknowledging all the other scripting languages out there. But I think I need to read that first line as having an implicit "...in the JS/TS ecosystem", and then it all makes sense.

Since clearly one of Deno's draws is that it improves on the package management of Node, I was wondering why JS projects so often end up with such a long list of dependencies, compared to the Python/Go/C++ projects that I'm more familiar with. That's probably explained just by NPM making it easy, so people did it. (Sort of like how Java grew convoluted DI schemes because OO + GC + reflection made it possible.)

One of these days I should learn more JS than having read through the Good Parts once. :-)

</comment></comment></comment><comment><USER47> Can someone explain to me what problem that Deno and Node are trying to solve? Is JavaScript really such an amazing language that we need to use it for backend applications now?

What niche is it filling that is unfilled by other, more sanely designed programming languages?

I'm not trying to be obtuse or anything, I'm just really curious as to why anyone would use Deno (or Node for that matter) for a project when I can think of at least 4 alternatives that are more sane (Go, Python, Rust, Java, and many more out there, just that these are the ones I'm most comfortable with).

<comment><USER48> This seems like trolling more than a genuine question, but I'll answer in case it is genuine.

It makes it easier for fullstack developers since it's a single language both in the front-end and back-end. You only need to learn once how `JSON.parse()`, `atob`, classes/prototypes, etc. work, and not worry about language inconsistencies making errors.

It is decently efficient (not the best, not the worst), fairly readable (I'd say on the upper side). The three main disadvantages IMHO are:

\- Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages

\- Node.js standard library is optimizing for flexibility instead of conciseness or completeness, so there's quite a bit of manual gruntwork involved (not the worst of those mentioned though).

\- Right now the ecosystem is in a major migration from `require()` to `import`. The last large migration like this was from Callbacks to Promises, and IMHO it went very well.

As someone who is very comfortable with Javascript, and was comfortable with PHP and Python back in the day, I would not trade Node.js for any of those. I am thinking most of the time about what I want to achieve in a coherent way, and not fumbling with pointers.

<comment><USER49> > \- Its async nature is more difficult to grasp for beginners compared to one > thread/request and then linear-ish work of some other languages

Grasping isn't the hard part, it's just about placing callback functions on executed functions that allows callbacks.

What's so bad is that it is async by default and now you need million "await" and "async" keywords all over the place. I wish it would be sync by default and for those rare cases where you really want it async, you would add a keyword.

<comment><USER48> I mean 4 of the very common Node.js operations are async by nature: database calls, file access, external API calls and crypto.

<comment><USER50> They aren't async by nature, just time consuming. Async is a useful way of dealing with time consuming operations in some situations, but blocking calls also a work (and make more sense for some workloads.)

</comment></comment></comment></comment></comment><comment><USER51> I still think that sandboxing dependencies is the wrong answer to this problem.

(first - the problem is trusting dependencies. How to spot malicious code in a dependency, and stop an evil upstream maintainer from doing bad things to your site)

This solution slows down the system at run-time (and also never quite solves the problem - sandboxes are pretty leaky. The history of browser extensions trying to do the same thing is a good example).

I'm not really sure what the solution is. I have some ideas, but they're mostly about changing the culture around coding, rather than technical.

<comment><USER52> Having sandbox restrictions available allows deeper defence. When it comes to running other people's code, VM restrictions provide a solid layer of protection.

At work we're transitioning our NPM scripts to run in containers. This is very cumbersome. But the extra layer protects dev homedirs from rando NPM authors.

</comment></comment><comment><USER53> Deno is awesome. We had a similar idea at Yazz Pilot and are currently building out the ability to import a subset of Javascript code from a URL. Currently it only supports code of the form:

pilot [https://raw.githubusercontent.com/zubairq/pilot/master/start...](https://raw.githubusercontent.com/zubairq/pilot/master/start.js)

</comment><comment><USER44> Interesting, so by making dependencies in the code itself, which is more obtuse than using node modules, we might see fewer overall packages being used by developers, and more implementations from scratch. No more gigabyte sized node modules! I'm looking forward to this.

<comment><USER5> Right!

[https://deno.land/x/is_url](https://deno.land/x/is_url)

[https://deno.land/x/blox](https://deno.land/x/blox)

[https://deno.land/x/deno_flatten](https://deno.land/x/deno_flatten)

[https://deno.land/x/ende](https://deno.land/x/ende)

[https://deno.land/x/humanize_url](https://deno.land/x/humanize_url)

There are many others. I don't know why people aren't looking into std (which provides most of the functionality) or using regex where it doesn't make sense given deno is a browser.

<comment><USER54> Well hopefully people find it too annoying to use deno modules and we get some sanity in development.

</comment></comment></comment><comment><USER55> I'm still not sure how this addresses Laurie Voss's point about left-pad. Does the caching and lock file happen by default?

</comment><comment><USER56> > The Deno CLI works like a browser, but for code. You import a URL in the > code and Deno will go and fetch that code and cache it locally, just like a > browser. Also, like a browser, your code runs in a sandbox, which has zero > trust of the code you are running, irrespective of the source.

Guessing it uses containerization or virtualization, hopefully with no gaps in security.

<comment><USER57> I don't know that it uses either of those tools as the built-in approach. It could have changed, but last I read, it used V8's built-in Isolate concept to provide the sandbox and that when an Isolate is created, it is only provided the underlying system access specified by CLI flags or other options e.g. Filesystem, Network, etc...

<comment><USER58> According to its architecture description ¹, there are no containers or virtualization involved in Deno.

I found deno::CoreIsolate in the source ². Userland process isolation seem to be provided by V8 Isolate.

The execution and security model remind me of recent trend in FaaS, in particular running WebWorkers (or similar), WASM, etc. Found a fascinating presentation about how V8 is used at CloudFlare ³.

"..using V8 isolates instead of containers or VMs, achieving 10x-100x faster cold starts and lower memory footprints.."

\---

¹ [https://deno.land/manual/contributing/architecture#schematic...](https://deno.land/manual/contributing/architecture#schematic- diagram)

² [https://github.com/denoland/deno/blob/2610ceac20bc644c0b58bd...](https://github.com/denoland/deno/blob/2610ceac20bc644c0b58bd8a95419405d6bfa3dd/core/core_isolate.rs#L77)

³ Fine-Grained Sandboxing with V8 Isolates - [https://www.infoq.com/presentations/cloudflare-v8/](https://www.infoq.com/presentations/cloudflare-v8/)

</comment></comment></comment><comment><USER59> Clear article, I honestly don't have much to add to the main thesis of it, other than that I'm very curious to see how well the arguments will hold up when faced with "real world" usage, and how Deno will evolve.

But if I may indulge in a bit of bike-shedding on the side, does anyone else think that the repeated URLs in the example dependency tree are a bit noisy and hide the deeper structure of the dependencies?

        https://deno.land/x/oak/examples/server.ts
          ├── https://email@example.com/fmt/colors.ts
          └─┬ https://deno.land/x/oak/mod.ts
            ├─┬ https://deno.land/x/oak/application.ts
            │ ├─┬ https://deno.land/x/oak/context.ts
            │ │ ├── https://deno.land/x/oak/cookies.ts
            │ │ ├─┬ https://deno.land/x/oak/httpError.ts
            │ │ │ └─┬ https://deno.land/x/oak/deps.ts
            │ │ │   ├── https://email@example.com/hash/sha256.ts
            │ │ │   ├─┬ https://email@example.com/http/server.ts
            │ │ │   │ ├── https://email@example.com/encoding/utf8.ts
            │ │ │   │ ├─┬ https://email@example.com/io/bufio.ts
            │ │ │   │ │ ├─┬ https://firstname.lastname@example.com/io/util.ts

I'm not entirely sure what would be the ideal alternative presentation though. Perhaps something along the lines of one of these two mock-ups I just edited by hand:

         https://deno.land/
           └─┬ x/oak/examples/server.ts
             ├── email@example.com/fmt/colors.ts
             └─┬ x/oak/mod.ts
               ├─┬ x/oak/application.ts
               │ ├─┬ x/oak/context.ts
               │ │ ├── x/oak/cookies.ts
               │ │ ├─┬ x/oak/httpError.ts
               │ │ │ └─┬ x/oak/deps.ts
               │ │ │   ├── email@example.com/hash/sha256.ts
               │ │ │   ├─┬ firstname.lastname@example.com/http/server.ts
               │ │ │   │ ├── firstname.lastname@example.com/encoding/utf8.ts
               │ │ │   │ ├─┬ email@example.com/io/bufio.ts
               │ │ │   │ │ ├─┬ email@example.com/io/util.ts

         https://deno.land/x/oak/examples/server.ts
           ├── https://firstname.lastname@example.com/fmt/colors.ts
           └── https://deno.land/x/oak/
                 └─┬ mod.ts
                   ├─┬ application.ts
                   │ ├─┬ context.ts
                   │ │ ├── cookies.ts
                   │ │ ├─┬ httpError.ts
                   │ │ │ └─┬ deps.ts
                   │ │ │   ├── https://email@example.com/
                   │ │ │   │     ├── hash/sha256.ts
                   │ │ │   │     └─┬ http/server.ts
                   │ │ │   │       ├── encoding/utf8.ts
                   │ │ │   │       ├─┬ io/bufio.ts
                   │ │ │   │       │ ├─┬ io/util.ts

I'm sure there are good arguments to be made against both of these options as well - plus I just came up with this on the spot, I don't even know which "rules" would generate such a tree.

</comment><comment><USER60> I think this is pretty good. I like the use of URLs as identifiers for your dependencies, just because it's so unambiguous. I also like re-exporting deps manually.

My only real point of discomfort is how the runtime seems to be a bit too closely tied to the actual download and transport of these files/URLs. Like, importing from https implying all further imports are from https is nice, I guess, but is really stretching the browser metaphor imo.

I guess that is really my main point of contention, I agree with the security model but I don't agree that websites are particularly analogous to code dependencies.

</comment><comment><USER61> The post sounds rather Javascript-specific, or NPM-specific. How well does that apply to other languages? Especially compiled ones?

</comment><comment><USER62> 2 reasons why this could be a faulty approach:

1) Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not have a never-ending variety. On the contrary, we do want to all arrive at one good way of doing a thing. This naturally invites a single central repository over the decentralization of the web.

2) Very few people publish their own websites. Why? It's complicated, costly. This is why Facebook and Twitter fair so well. So even the decentralized web eventually diverges onto a centralized platform that solves the hosting problem. Why reintroduce the problem when there is already a fairly un- problematic central registry?

If the security model is the real winner, I don't see why it could not be back-ported to Node - it likely will be if Deno takes off in any way.

<comment><USER63> I don't have an opinion on Deno per se, but I quibble with this part of your point:

> Code, specifically library code, which is what npm mostly consists of, in > its most ideal state should not have a never-ending variety. On the > contrary, we do want to all arrive at one good way of doing a thing.

This implies that there is in fact one good way to do most things, but in practice different people want different trade-offs and forcing them into a single codebase isn't possible when the options are mutually exclusive. You can't have a library that is simultaneously strict about types (panics if you pass a string instead of a number, say) and forgiving about types (automatically coerces strings to integers or vice versa).

</comment></comment><comment><USER64> Deno seems like the next mongo db fiasco waiting to happen. Insecure by default. The fact that it doesn't grant permissions by default is irrelevant, servers need permissions to function (access databases, access files, access the network, etc...).

The incentives are all wrong. If I MITM a website at best I gain access to the data of the few users that pass through my part of the net. If I MITM something Deno is using I get access to the server. That's orders of magnitude more data I get access too and therefore the incentive to MITM (or other) is much much MUCH higher.

<comment><USER65> I agree, they should force cached, sandboxed fetching by default and have people opt in to dynamic fetching.</comment></comment>


Humble indie fumble: an XBLA horror story - <AUTHOR> http://www.next-gen.biz/features/humble-indie-fumble-xbla-horror-story

<comment><USER2> I played an early build of Shuggy nearly four years ago when some of my colleagues were reviewing Dream Build Play games. Even back then, it was surprisingly close to a finished game; carrying a coat of polish that was very rare among the other contest entries. It was far and away my favorite game of the competition, so it was hard to watch it from a (pretty far) distance while it struggled to find its way to XBLA. When it finally did land, it didn't make so much as a peep.

This is a sad story, but let it serve as a warning: Publishers, just like any party in a business relationship, have their own priorities and motives. You need to understand those of whoever you enter into business with. And furthermore, you need to demand final cut for the key parts of your business, and that includes marketing yourself and your product. If you're not good at something, don't assume that getting another party to do it for you is a panacea. You need to become enough of an expert to know when they are doing you a diservice.

<comment><USER3> Also adds weight to the "Just Ship" mantra. Imagine releasing it 2 years ago, and using the time since then to promote it, update it, polish it (if XBLA allows that sort of thing).

<comment><USER4> Or create a second game in that time frame, with lessons learned from the first.

</comment></comment></comment><comment><USER5> I read it as a Humble Indie Bundle: an XBLA horror story and thought it was a story about Humble Indie Bundle. It's not. The story has nothing to do with Humble Indie Bundle. In fact this story goes on to show the need for something like Humble Indie bundle for xbox.

<comment><USER6> My heart skipped a beat when I saw the headline!

</comment></comment><comment><USER7> A story worth reading. I'm sad because I'm afraid of being in the same boat (although I'm just starting out basically). The takeaway from my perspective is this: pick the platform carefully as it may narrow your space of movement so much it might just screw things up for you; and secondly, do some marketing yourself if possible.

      [column inches, websites] may be easier than ever to do it
      yourself - but that doesn't guarantee anyone will care.

Apparently, letting the relevant department do it didn't guarantee anyone would care. If you're too much into coding, you may forget other aspects of business. Oh, and things sometimes fall apart even if everything is done the right way.

</comment><comment><USER8> I never understood the hope XBLA inspires. The ecosystem is limited and tightly controlled. Access to the market is entirely at the whim of Microsoft, who will also be your main competitor.

From the outside it looks like a huge trap for catching cheap IP as it develops.

</comment><comment><USER9> The story is not done, seems it will have a happy ending IF he ports it to Steam. Whats another 1-2 months doing that and getting some more multiple? But something tells me the contracts he's done restricts what he can do with the IP.

</comment><comment><USER10> I tried the game and passed on it when it was released. I can't speak for the general public, but it was not a failure of marketing for me. It just wasn't enough to get me to spend money on it. It was polished, and not _bad_ , just... sort of forgettable and average. It would be a big assumption for me to assume that my experiences are more consistent with what happened to the game in reality, but the article doesn't tell us how many trial downloads went along with the poor sales either.

<comment><USER7> There is a huge need for polished games under the radar. Even the forgettable part is forgivable. Polished is above average.

(I don't mean you should have bought the game. All I say is I don't understand why it didn't generate more sales in the indie community.)

<comment><USER10> Polish is nice to have, sure, but if nobody wants to actually play the delivered experience, all the polish in the world won't save it. Nobody should buy a game just because it's polished. While I'd prefer polish on all my games, I'll take an unpolished dwarf fortress over a polished forgettable uncompelling game any day of the week).

As a side note, I'm not sure what rule I've broken to get downvoted. I pointed out that there could be more to this story, and that we don't have solid data on how many trial downloads there were (which is a MUCH better indicator than sales is regarding "marketing" in this case).

For those unfamiliar with XBLA, just about everyone downloads a trial first (every game on XBLA is required to have a free trial, so you'd have to be pretty impulsive to skip it completely), and then you can buy the game from within the trial version's interface.

If the point of the comments here on HN is to add to the discussion, I'm not really sure what I did to justify a downvote. I'm just getting started commenting here and don't really have karma to spare. I really try hard to be a positive member of the site, so If somebody sees this and can point out what I can avoid doing in the future, that'd be appreciated.

<comment><USER11> You're doing fine. Just don't panic about downvotes so loudly -- that's one thing that _is_ considered bad form, if I remember correctly.

</comment></comment></comment></comment><comment><USER11> Glasgow may have a self-deprecating culture similar to that here in New Zealand. We've had to learn the hard way to be -- by our local standards -- incredibly pushy. Hopefully my business partner won't mind me quoting an article he wrote for Ars Technica [1]:

 _Then come the cultural differences (or perhaps they're just personality differences.) Whether it's a New Zealand-wide trait or not, we tend to talk ourselves, and our products, down. To boast about how great you think you are seems arrogant and obnoxious, but when you're trying to get people excited about your games, underselling it (and yourself) can backfire horribly.

I've seen the same confused facial expression from many overseas visitors when I modestly described my game as "alright." If the creator doesn't think his game is totally super awesome, they seem to be thinking, then why on earth should I check it out? We've had to learn to talk our games up. Even if it makes you cringe inside, developers have to show others why they're spending their life making these things!_

[1] [http://arstechnica.com/gaming/2011/01/sell-in-america- live-i...](http://arstechnica.com/gaming/2011/01/sell-in-america-live-in-new- zealand.ars)

</comment><comment><USER12> Isn't indie game development all about being self-publishing aka independent aka _indie_?

</comment><comment><USER13> It was difficult reading that article since it had so many grammatical errors, but worth it.

<comment><USER11> You must have a keener eye than me: where were these errors?

<comment><USER13> I'm not the editor for that site so it's not my job. Not sure why I get downvoted for pointing out the horrible writing.

<comment><USER11> Not that I downvoted you, but is it because no-one else is able to spot any errors?</comment></comment></comment></comment>


What If there was no Moon? - <AUTHOR> https://www.economist.com/the-world-if/2018/07/05/empty-sky-empty-earth <comment><USER2> 'Were no,' not 'was,' it's the subjunctive tense.</comment>


Nishiyama Onsen Keiunkan: The oldest company in the world - <AUTHOR> https://the-pastry-box-project.net/natasha-lampard/2015-march-27

<comment><USER2> I think the title could be better worded to reflect the content of the article - It's about an "exist" strategy, not an "exit" strategy for startups and companies.

About being a "longtrepreneur" \- being an entrepreneur but with the goal of staying.

</comment><comment><USER3> I love the random quote from "Withnail & I" in this - "A certain 'je ne sais quoi' oh so very special", spoken by the late, great Richard Griffiths.</comment>


Show HN: Typomatic – add animated text to videos - <AUTHOR> https://itunes.apple.com/us/app/typomatic-add-text-animation/id1097518424?mt=8&ign-mpt=uo%3D4 <comment><USER2> Curious if there are plans to apply the algorithms to other platforms.</comment>


Clinician impact and financial cost to NHS of litigation over pregabalin - <AUTHOR> https://www.biorxiv.org/content/early/2018/02/17/266403 <comment><AUTHOR> One of the authors of this piece has some involvement with OpenPrescribing.

In England all prescription info is open. We can use that to try to reduce prescribing of meds that have more effective alternatives, or that have cheaper as effective alternatives, or that are dangerous.

[https://openprescribing.net/](https://openprescribing.net/)

<comment> cirrus-clouds Another example: anti-cancer drug Avastis has been found to be effective against blindness in old age (wet macular degeneration). The current drug for preventing wet macular degeneration is Lucentis, which costs 10 times more than Avastis.

Twelve NHS clinical commissioning groups (CCGs) have recommended switching to the cheaper (and just as effective) Avastis drug. But Novartis and Bayer, who market the more expensive Lucentis, have threaten legal action over the use of the cheaper drug.

[https://www.theguardian.com/society/2017/nov/01/drug- giants-...](https://www.theguardian.com/society/2017/nov/01/drug-giants- threaten-nhs-with-legal-action-over-cheaper-drug-that-could-save-84m-a-year)

<comment><USER2> And this is the concern of agreements like TTIP, where companies can sue government policies that result in lost revenue.

Obviously there are some benefits - i.e. governments deliberately creating regulations that make competition difficult and essentially recreating protectionism while reaping the rewards of a free market, so I can see why it is a good thing, but it could easily be abused.

</comment></comment></comment><comment><AUTHOR> The full title is "The clinician impact & financial cost to the NHS of litigation over pregabalin: a cohort study in English primary care | bioRxiv" \- too long for the 80 char limit.

</comment><comment><USER3> A family member spends $450 US per month on Lyrica/pregabalin. I wonder if this patent decision could result in a rebate for individual patients.</comment>


The point of writing software isn't to maintain it forever - <AUTHOR> http://richo.psych0tik.net/blog/2013/04/24/the-point-of-writing-software-isnt-to-maintain-it-forever/

<comment><USER2> Eternal maintenance is not the point of writing software; it's just an unfortunate inevitability.

<comment><USER3> Exactly. And the example given (cron) was designed with the Unix-mentality of writing a program that does one thing really well and does it without breaking. Yeah, sure, some may argue that cron is fairly complicated, but it doesn't suffer from the maintainability needs of a _very_ complex piece of software like some enterprise systems.

<comment><AUTHOR> Shouldn't that be what we're striving for?

Much though I really hate to admit this, npm and the node community are on the right track here.</comment></comment></comment>


Why Textbook Prices Keep Climbing [audio] - <AUTHOR> http://www.npr.org/sections/money/2014/10/03/353300404/episode-573-why-textbook-prices-keep-climbing <comment><AUTHOR> The main explanation given to justify $300 price tags for textbooks is the short "exploitation window" for each title. Because of used book sales, new book sales are eroded, so publishers are forced to jack up prices. Hm... I like how publishers end up the victims in that story.

Also interesting is the part of the interview with an executive from a big publishing company who seems convinced digital textbooks are the future. Sure. Maybe. I wonder if they asked teachers what material/tools they need for better teaching, or if they came up with the strategy on their own. I'm not so sure "digital editions" will be very good. If they use DRM, then the reader experience will be crap, and if they don't then piracy will hit them much harder.

<comment><USER2> Yeah I liked that bit about digital tools. I've spent the last five years or so at my last two schools dealing with issues with subscription based "eBooks" that don't play nicely with education department proxies, crappy Flash learning objects, or are just unresponsive.

All this makes me so sad since I try to evangelise effective use of IT in classrooms.

</comment></comment><comment><USER3> I'm really surprised that piracy hasn't been pushing them to more a more reasonable price point, like file sharing did with music. When I went back to school, almost every single one of my textbooks was available in some pirated form. Sometimes one had to settle with the previous edition, which was usually identical to the current edition with some pagination changes. It can be a bit of a pain to get them, but it wasn't $300 per book's worth of pain.

<comment><USER4> Using a pirated textbook is not as easy as listening to pirated music. Paper is actually a pretty good form for textbooks and printing hundreds of pages is not fun, binding them in a useful way is even less fun. Sure, you can just print out the snippets that you need to work with at the moment, but that's not very convenient.

</comment></comment><comment><USER5> i guess with today's smartphones you can just flick through the pages one by one while filming, and then you'll have a video you can pause at any page, with sufficient resolution to read it.</comment>


Ask HN: Why doesn't the HN user's submissions list show number of comments? - <AUTHOR>

<comment><USER2> It does, just older articles don't show number of comments (probably after a post is out of the servers memory).

Go on the front page and click a users name, go to submissions and you'll see the comment number on the submission that is on the front page.

<comment><AUTHOR> Yep that's how I found yours... thanks! :)</comment></comment>


2020 democrats on (web) accessibility and disabilities rights - <AUTHOR> https://docs.google.com/spreadsheets/d/1hwHfVgFSzJDPm1hJib1dBXNHAVHD9n80ISRuQ80bHfQ/edit?usp=sharing <comment><AUTHOR> I put together a comparison of the 2020 Democratic primary candidates on disability rights and accessibility.

Especially relevant to my developer followers who are fellow web accessibility advocates</comment>


Would there be less spam if Mechanical Turk cracked down on jobs like this? - <AUTHOR> https://www.mturk.com/mturk/searchbar?selectedSearchType=hitgroups&requesterId=AK6QCLOJ9AQP3

<comment><USER2> Is this even against their policies? It strikes me as a hard policy to write. Compare it to "write and distribute a whitepaper about XYZ". That certainly sounds like a legitimate task, but it is only different from this example in scale.

At least if they decide to to forbid this practice, they can pay their own turksters to find and flag the forbidden activities.

<comment><USER3> _Mturk > FAQ > Policies:_ You may not use Mturk for spamming activities. (<https://requester.mturk.com/mturk/help?helpPage=policies>)

Workers may flag any HIT they feel violates Mturk policy. Flagged requesters risk getting banned by staff.</comment></comment>


The Chapel. A short HDR timelapse film. - <AUTHOR> http://lookycreative.com/lang/en/portfolio/the-chapel-hdr-timelapse-film/

<comment><USER2> The only thing compelling about this was the ending title card.

<comment><AUTHOR> Ah I didn't care much for that. Obviously we're appreciating different parts of "this".

For me, there is something beautiful / mysterious about the interplay of light amidst the ruin and dust particles whirling about.

The magnificent architecture by <http://en.wikipedia.org/wiki/Carl_Gotthard_Langhans> comes a close second. He probably would have gotten rave reviews from HN if alive today:

" He was not educated as an architect. He studied law from 1753 to 1757 in Halle, and then mathematics and languages, and engaged himself auto- didactically with architecture, at which he concentrated primarily on the antique texts of the Roman architecture theorist Vitruvius (and the new version by the classics enthusiast Johann Joachim Winckelmann."

<comment><USER2> Perphaps I'm just turned off by the highly exaggerated and artificial tone mapping of most HDR. Generally I think using conventional techniques would have featured the architecture much better. HDR looks best when it expands the range of conventional techniques while still mimicking their perception. In this sense Ansel Adams was a master of HDR.

This sort of HDR reminds me of early stereo recordings that would ping pong sounds between the channels using panning.

<comment><AUTHOR> All the commentators on this post including yourself are the experts regarding the actual tech they're using. I don't know enough about their technique .. and probably won't unless I make new friends ;-).

Perhaps, the way to look at it is that these guys seem to have put in a lot of effort and heart into it. The music's kinda nice too.

May be you all should leave a comment on their page so that the improvements could be implemented. Am fairly sure they have the raw footage, so like software, they can release a new version :-).

</comment></comment></comment></comment><comment><USER3> I liked the non-HDR parts of that video much more.

I hate that HDR look in photos. The effect looks interesting in the video, it makes it look like a computer rendering. Still gimmicky though.</comment>


Productivity vs. Guilt and Self-Loathing - <AUTHOR> http://www.hanselman.com/blog/ProductivityVsGuiltAndSelfLoathing.aspx

<comment><USER2> Somewhat ironic that I found this through HN where I so often feel that the world is moving so much faster than I can possibly keep up. Some of the work produced and shown here is just superb, and so often I get the feeling of:

 _Everyone seems to be getting stuff done, except you._

I so often think that productivity, guilt and self-loathing go hand-in-hand. I've been wondering if entrepreneurs are particularly susceptible to to the dips and highs that come from these three things locking together, or if everyone feels that way?

<comment><USER3> Everywhere in the world, people are getting stuff done.

Don't sweat it, just remember to go at your own pace, challenge yourself on a daily basis, and be proud of your accomplishments. We all run at different strides, don't judge yourself based on someone else's accomplishments.

I sound a little preachy, but hey, we all need the pep talk sometimes. :)

<comment><USER4> > Everywhere in the world, people are getting stuff done.

A person in a depressed state of mind would answer: " _Except_ me!" To themselves though, since they're aware of that fact and it can only make them feel worse. Why can't they just be productive? They're quite capable of repeating the various motivational mantras out there; those are more likely to just contribute negatively to the feedback cycle they're in.

</comment></comment></comment><comment><USER5> I definitely see where he's going with some of this stuff, but I strongly disagree with this part, and I find it really off the mark:

      You know that pile of books that you'll never read that sitting
      next to the computer you are reading this blog post on? That pile
      is too tall. You'll never read all those. That pile of books is a
      monolith of guilt. It's a monument of sadness and failure. Pick
      the book or two that you can read this week and put the rest
      away.

"A monolith of guilt... a monument of sadness and failure"?! How pessimistic! No, no, it's a pile of treasure! I love having a huge stack of books on my desk, or overflowing from my bookshelves. Maybe he's talking about a different kind of book, but almost none of the books I'm currently reading I'll be able to finish in a week, not even if I devoted all my free time to a single one. Here's my current stack:

Modern Compiler Impl in ML, Real World Haskell, Programming Haskell, Types and Programming Languages, Software Foundations, chapters on parsing in EOPL1, chapters on types in EOPL3, chapters on types in PLAI,

And that doesn't include some papers I've got printed out for the subway. I just got a new book delivered today, bought practically on a whim (the Coq'Art book), just because why not? Maybe I have some kind of attention deficit problem, but I really find it valuable to read multiple takes on the same topic (in this case, as you might infer, compilers and types), which means working through a bunch of books concurrently.

I find it thrilling and exciting to have so much _more_ to read, so much more to learn. The stack of books is a monument to wonder and knowledge, it's a deep well to draw on and to be immersed in.

<comment><USER6> I think his point is that if the unread books are right in front of you for months at a time, they are a constant reminder that you mean to get around to reading them, but never do.

Which is something I definitely agree with. I used to have books lying around my room. Not only were they visual clutter, but I would get in the habit of picking one up, flipping through the pages, and then getting distracted with another book. Ever since I started keeping all my books in my bookshelf though, I've been much better at focusing on just one and finishing it before moving on to the next.

<comment><USER7> That is the entire point of having the books in a stack where you can see them!

I love reading, but I intentionally take up books for leisure reading that I know will be a challenge. Some longer or more difficult works are definitely projects, projects that I need to consciously put work into.

Having the book sitting out there, visible, a physical reminder, is probably my most powerful motivational tool for getting these books read. For me this is the main reason I still buy and read physical books.

I guess it also helps that, for me, reading is something I get excited about. It is how I unwind. Having a book in my library that I haven't read yet does not make me feel guilty. Maybe the book makes me excited with anticipation, maybe I feel apathetic towards it. But I don't feel anxious, because the world will keep spinning just fine if I fail to read a book.

edit: I should amend to say that this is also a matter of taste. Having books all over the place will definitely make you switch reading material sometime, and will probably keep you from finishing some books. I'm of the school of thought that says, fine. I'll fail to finish some books. Not the end of the world. Sometimes a book just takes a couple of tries before it gets its teeth into you.

<comment><USER8> I'm not saying that one shouldn't have a lot of books. I've got a bookshelf behind me that is TWO WALLS wide and 8 feet tall. I'm talking about the pile of books on our desk that we lie to ourselves about. I called them Guilt Piles.

For many people that pile of books that they aren't going to read this week represents promises they've made to themselves that they didn't keep. I was just saying, be honest and take a few books off your desk. Those books are on my shelves and I'll read them when I'm ready for them.

<comment><USER7> All I can say is that I live in a state of radical disarray, and I often have books just sitting around. I wouldn't ever call them guilt piles, because leaving something unfinished causes me no real guilt, especially if I'm happy with whatever I'm doing at the moment.

In my work life, I feel I need to fight that instinct. But not in my reading life. That's part of what makes it a refuge for me.

</comment></comment></comment></comment></comment><comment><USER9> Comment I posted on this article:

Great post, Scott. Here are some things I do to build off your main points:

Stop Checking Email in the Morning - Batch email checking into something you do two or three times per day at certain times.

Don't make Guilt Piles - If you do make them, keep them out of site and accumulate them for a long plane ride, car trip, or vacation.

If it's important, Schedule It. - Again, I schedule my email and my browsing .I actually roughly schedule my whole day. Happy to send to anyone just email me at wu at skim dot me.

Let go of Psychic Weight - This is a hard one but the key to overcoming digital overconsumption and information overload is to recognize you'll never be able to get through it all.

Schedule Work Sprints - I have two one and a half to two hour slots of real productivity per day. Sometimes I get to three.

Stop Beating Yourself Up - Constant struggle

I'm somewhat new to this productivity thing but got into it after recognizing that my web browsing was becoming addictive and unproductive. It was producing "the guilt and self-loathing" you mentioned if I couldn't keep up with it. It ultimately led me to build Skim.Me. We're making your daily online browsing routines more productive. Not just tools or a platform but really an entire user experience that wants to move content consumption away from addictive page views and time spent towards a disciplined approach to building better, sustainable habits.

We automatically onboard you using our plugin, aggregate from your favorite sites/apps (not just news & social) across devices, and help you browse in timed batches through the day without showing you how many unread or unchecked you have. Hope some people check it out when we launch (<http://skim.me>). v1 in three weeks.

<comment><USER10> " I have two one and a half to two hour slots of real productivity per day. Sometimes I get to three."

I'm relieved I'm not the only one who only really gets 3-4 hours of productive work on an average day.

<comment><USER11> You are more productive than most people, according this Quora's answer. [http://www.quora.com/How-many-hours-do-most-people- actually-...](http://www.quora.com/How-many-hours-do-most-people-actually- work-in-a-day)

</comment></comment></comment><comment><USER12> See Spolsky's "Fire and Motion" for a far better take on this.

<http://www.joelonsoftware.com/articles/fog0000000339.html>

</comment><comment><USER13> I feel guilty now. I've been reading HN for 2 hours.

<comment><USER13> Actually, if I'm honest with myself, 3 hours.

<comment><USER14> Lol ... its okay. Time yourself and cut it down to 2.5 hours tommorrow.

Tiny steps are okay as long as you make a lot of them ...

</comment></comment></comment><comment><USER15> I use HN reading as a reward when boring work is done. It works well.

</comment><comment><USER16> Another way to keep track of your time is to run a screen-recording software through the day, and then do a review In the evening.</comment>


Implementing a Sticky Input Field in iOS - <AUTHOR> https://medium.com/@meiwin/a-stickler-for-details-implementing-sticky-input-fields-in-ios-f88553d36dab

<comment><USER2> Interesting work, thanks for sharing.

      The input field is subview of the keyboard's window. This is likely undesirable, especially for chat applications.

I am curious as to why this is undesirable. It makes sense to me that something docked to the keyboard would be in the same window.

<comment><AUTHOR> It's because the input field will always appear at window level above the level of key window. So, if you need to show overlay in key window, the input field will appear above the overlay. Example for such overlay could be a loading indicator.

</comment></comment><comment><USER3> I love this. I've actually been using [https://github.com/AlexLittlejohn/ALTextInputBar](https://github.com/AlexLittlejohn/ALTextInputBar), but this is a well written explanation and solution to the problem.

<comment><AUTHOR> Thanks, glad you find it useful.

</comment></comment><comment><USER4> Or you can use Slack's open sourced version: [https://github.com/slackhq/slacktextviewcontroller](https://github.com/slackhq/slacktextviewcontroller)

<comment><AUTHOR> hi Aaron, I did briefly look at SlackTextViewController. But decided not to use it because the project contains many features that we do not need. Furthermore, it doesn't support usage on iPad.

</comment></comment><comment><USER5> There's no mention in the article that since iOS 7, there's been a "UIScrollViewKeyboardDismissMode", which allows "interactive" dismissal. It isn't perfect, but the last time I investigated, too many solutions out there involved touching private APIs.

<comment><AUTHOR> I could've more explicit.

Interactive dismissal only made possible with UIScrollViewKeyboardDismissModeInteractive introduced since iOS 7.

This article described solution for interactive dismissal with `sticky` input field atop the keyboard.

<comment><USER5> In 2015, most apps shouldn't support anything below iOS 7.

Create a constraint that attaches the input field to the bottom of the scrollview.

One tradeoff is that dismissal doesn't start until your touch enters the real keyboard area. I'll take it, since it's safer than using KVO to observe private APIs.

<comment><AUTHOR> Hi sandofsky, that was our previous implementation (dismissal starts only when user's touch enters the real keyboard area) - it doesn't feel 'right'.

The library is not really using KVO to observe private APIs, bounds/center of UIView is public property.

<comment><USER5> You're observing the superview in a hierarchy you don't own. In your code, you have an iOS version check, presumably since the property you're looking for changed between iOS versions.

<comment><AUTHOR> yes, that I agree, it may break between iOS versions. i'm all ear to other approach if any

<comment><USER5> You file a ticket with Apple and stick with documented APIs.

<comment><AUTHOR> will do and hope Apple may do something about that.

until then, will stick to current solution and test ahead of any new iOS release.

<comment><USER5> You've decided on the path of higher maintenance, and you've increased the risk of Apple rejection.

Maybe this decision won't bite you, but this mentality will.

<comment><AUTHOR> i keep my options open until I find a better solution.

i'm assuming engineers that build FB messenger, WhatsApp, Twitter etc. could be using similar approach, but I am more than happy to be proven wrong.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> This is such a great writeup, thank you for digging into it. Have you tried this out with iOS 9? I know JSQMessagesVC, which does a really solid interactive dismissal, has some problems with that.

<comment><AUTHOR> Hi, it works in iOS 9. The Pie for iPad screenshot in the post is running in iOS 9.</comment></comment>


Floppy Drive Reverb. Recording Analog Audio on Floppy Disks - <AUTHOR> http://www.youtube.com/watch?v=Xpr7B-7BFP4&feature=related

<comment><USER2> When I saw the title, I recalled the sounds that the old Apple floppy drives would make: when you booted them up you could hear the chunka-chunka-chunka as the stepper motor pushed the head all the way to the outer track, and then a little scraping noise when (after the rest of the driver had been read off the outer track) the head moved to the center track to read the directory. And the farting noise it made before the console beeped and said "I/O ERROR"... those were the days... kids today, they don't know what it was like....

</comment><comment><USER3> Well, now I know how the Cocteau Twins made their sounds in the 80s!</comment>


If Management is the Only Way Up, We're All F'd - <AUTHOR> http://moz.com/rand/if-management-is-the-only-way-up-were-all-fd/

<comment><USER2> This is the way MSFT does things, and I hated it. (Don't get me wrong, this isn't a blind MSFT bashing response, this is something that directly affected my career there. If you're there YMMV but this was clearly my experience in my BU.)

During the review cycle, you were given, more or less, two ratings. A performance rating based on your current performance, and a rating based on the company's opinion of your ability to "rise through the ranks".

I liked what I did there. I did well at it (not just my opinion, but that of others and consistent performance reviews). I was comfortable with the job, the responsibilities, the pay and benefits, and the job provided a good challenge and no real risk of boredom or burnout. In short, I liked what I did and enjoyed the prospect of continuing to do that job.

That is career poison there. No matter how good you are in a position, and how much you enjoy it, your incentive is to keep moving up and if you're not so eager to do so, that's seen as a career limitation.

I was at the top end of the technical path I was in, and my next step up was to become management and manage employees who would be doing the job that I was doing now. MSFT saw that as a good career path, to take me away from a job I enjoyed, and put me in the position of curating other employees to do the job I enjoyed doing.

I understand a company's desire to make sure their employees are continually on a career path, but you can't move everybody up the ranks all the time. Sometimes the best employee you can have is one who's a good fit for a position and likes being in that position for a while.</comment>


Show HN: GoPexo, a next generation vacation planner for group travel - <AUTHOR> http://gopexo.herokuapp.com

<comment><AUTHOR> We are building a collaborative trip planner for friends and family. The service will help you collaborate on your itinerary, organize your budgets, and figure out cost-sharing.

This is our landing page, please check it out and tell us what you think!</comment>