Launch HN: DeepSource (YC W20) – Find and fix issues during code reviews - <AUTHOR> Hi HN! We're Jai and Sanket — founders of DeepSource (https://deepsource.io). We're automating objective parts of code review using static analysis to ensure the code is free of common issues (anti-patterns, bug risks, performance bottlenecks, and security flaws) before a reviewer looks at it. This prevents the reviewer from having to manually point out objective issues and ensures they don't make it to production.
After college, Sanket co-founded DoSelect where I joined as the first engineer. Both of us have been contributing to open-source projects for a few years then. In the beginning, we didn't have any processes setup around code reviews. We had some IDE plugins to run the linters, and some team members used them as pre-commit hooks. We didn't have any tests back then and used to spend too much time on some pull requests pointing out improvements and if the pull request was very large, we never reviewed it — direct merge. Then the engineering team started to grow, multiple folks started contributing to the same repositories and pull requests were often stuck for 5-7 days without any activity. To make sure the new commits are free of the common issues, we added multiple static analysis tools as part of our CI jobs. This became a pain sooner than expected as they were throwing hundreds of lines of logs in the CI and we had to fight through duplicate issues. Critical issues were hidden amongst other minor issues and false-positives, and often missed. Once a while, we tweaked the linter config files with the issues that didn't make sense to us — to reduce noise in the CI logs. It didn't work out after a while and we invested in a couple of commercial code quality tools but ended up disabling them as well. Their issues weren't categorized or prioritized, analyzers were never updated with new rules, didn't have any way to report false-positives.
We came across a paper — Lessons from building static analysis at Google [1]. It is a beautiful paper with the following insights: 1) Static analysis authors should focus on the developer and listen to their feedback 2) Careful developer workflow integration is key for static analysis tool adoption 3) Static analysis tools can scale by crowdsourcing analysis development.
We started building DeepSource in December 2018. The initial release supported Python and integrated with GitHub. Our approach was to first curate all the issues available from open-source static analysis tools, de-duplicate them, add better descriptions with external reference links — so you just add python analyzer to the `.deepsource.toml` file with some metadata (version, test patterns, exclude patterns,.) and analysis will run on every commit and pull request. To cut down the noise, we only show you newly introduced issues in the pull-request by default, based on the changeset — and not all the issues present in the changed files. We also provide a way for you to report false-positive issues directly from the dashboard. If the report is valid, we update the analyzers to resolve it within 48 - 72 hours. After this release, we started writing our own rules by walking through the Abstract Syntax Tree to find patterns. So far, we've 520+ types of issues in the Python analyzer. Some of the custom issues we added recently are: File opened without the `with` statement, using `yield` in comprehension instead of a generator expression, use items() to iterate over a dictionary.
A few months back, we released the Go analyzer and also added support for GitLab. We're working on supporting Ruby and JavaScript and integrations for Bitbucket and Azure DevOps. The analyzers are not limited to programming languages, and we added one for Dockerfile and Terraform as well. DeepSource is free to use for open-source repositories and we make money from private repositories based on a per developer per month/year subscription.
Lately, we realized some of the issues were occurring in tens of files. Though DeepSource reports them, one had to manually fix all the occurrences. We just released autofix support in Python for 15 most commonly occurring issues to start with. Autofix uses Concrete Syntax Tree to visit the issue location and make modifications in the code for which the issue is raised, and then generate a patch for that modification. When an autofix is available for an issue, you can view the suggested patch and on approval, a pull request will be created with the fixes. We're working on improving the coverage of issues we can autofix across the analyzers we support.
Give us a try: https://deepsource.io/ Here is the documentation: https://deepsource.io/docs/
We would love to hear your experience using these tools and feedback/suggestions on how can we improve! Please let us know in the comments. We're also at founders [at] deepsource.io.
[1] https://research.google/pubs/pub46576/ <comment><USER2> > Enable analyzers by adding .deepsource.toml

Why is this needed? Can't you imply the necessary analyzers from my codebase?

There is no support for Javascript, Typescript, PHP, Java or C#. No HTML or CSS support. Is there a roadmap?

Also, the name implies use if Deep Networks and AI. Am I mistaken? If not, what kind of AI is used here? Seems like just an automatic runner of static analysis tools.

<comment><AUTHOR> > Why is this needed? Can't you imply the necessary analyzers from my > codebase?

Sure. We can probably infer the languages used in the repository. But we need metadata like test glob patterns, exclude patterns, runtime versions (Python 2, Python 3) to improve the accuracy of issues. For ex: Usage of assert statement in application logic is discouraged as it is removed when compiling to optimised byte code (python -o producing *.pyo files). Ideally, assert statement should be used only in tests. Also, we haven't found a way to infer Python 2 vs Python 3 accurately. Can you think of a way? That would be helpful.

> There is no support for Javascript, Typescript, PHP, Java or C#. No HTML or > CSS support. Is there a roadmap?

We strongly believe in starting out with a few languages and add as many issues as we can (with the ability to autofix most of them) -- before we go broad. That said, we released Ruby in beta couple weeks back and are currently working on the stable release. We've also started working on JavaScript (with TypeScript support) a month back and we should release the beta version of JavaScript analyzer in approx a month from now.

> Also, the name implies use if Deep Networks and AI. Am I mistaken? If not, > what kind of AI is used here? Seems like just an automatic runner of static > analysis tools.

It's just the name :) We do not use Machine Learning or AI at the moment — the reason being we're optimizing for high accuracy, and a rules engine that uses AST parsing helps us do that reliably. We do plan to use learning in the future to capture data around which issues are being fixed the most and which are not, and then show issues in the most relevant order to users depending on their context.

</comment></comment><comment><USER3> Congrats on the HN launch guys :) Excited to see Javascript being added to the list of supported languages soon.

<comment><USER4> How can we get notified when Javascript (Node.js?) support launches?

<comment><AUTHOR> We'll tweet about it at [https://twitter.com/deepsourcehq](https://twitter.com/deepsourcehq)

</comment></comment></comment><comment><USER5> How is this different (or better?) than existing products that offer the same service, such as Codacy.

Have been a paying customer of Codacy's for ~2 years and they support most languages out of the box at this point, with Git integration similar to your own.

Curious on your thoughts.

<comment><USER6> A few differentiators:

* More issue coverage — for Python, we detect 520+ issues. We also enable you to run things like type checking (if you're using type hints) just by enabling it in the config.

* Custom issues — we have an analyzer team that keeps adding new, novel checkers to the analyzer for common bugs and anti-patterns.

* Fewer false positives — we've optimized our analyzers for reporting less than 5% false positives. On the lowest level, we write augmentations to each checker to remove known false-positives and noise. On the application level, we enable users to very easily ignore issues (for a file, all test files, some file patterns), and also report a false positive. We monitor all false-positive reports and proactively improve our analyzers to resolve them.

* Autofix — we just released this, which allows you to automatically fix some commonly occurring issues directly from DeepSource. In future, we will add more autofixers for issues, so at least 70% issues that we detect can be reliably autofixed.

<comment><USER5> Based on the points above, I am still not convinced this is significantly better than existing players, but I could be wrong. Additionally, some of the problems you've mentioned in other comments have already been solved by your competitors.

Do you think the fact that you're a late entrant into this market makes it difficult and/or challenging for your team? Why have your customers chosen you over other platforms? I'm mostly curious and not trying to put you down.

</comment></comment></comment><comment><USER7> Congratulations on the launch! Have been following the team's progress for a while and truly impressed with the pace of feature development while keeping the core product extremely simple. Happy to be a customer.

</comment><comment><USER8> This looks awesome - congrats on the launch.

Quick question: I tried setting it up but its asking for Write access to the pull requests. I am a bit wary about giving write access - is this required?

<comment><AUTHOR> There are two GitHub apps we maintain. One with read access (DeepSource) and one with write access (DeepSource Autofix).

By default, on signup, you would be installing the app with read access -- this enables us to pull source code from GitHub on every commit and pull- request, run analysis and report issues as GitHub checks. This is sufficient if you would like to use DeepSource only to flag issues.

With the release of Autofix -- when a fix is available for a flagged issue, DeepSource creates a pull request to the repository with the patch. For this, you would be asked to install the app with write access (DeepSource Autofix). Note that, DeepSource always creates a separate branch with the fixes and creates a pull request. We do not perform any write operations beyond the above mentioned scope.

</comment></comment><comment><USER9> This is a serverside pre-PR hook for an analyzer, as I understand it.

I was hoping this was a code review tool that allows you to modify the PR without making a commit-merge-push loop, which could have approved changes automagically pulled locally (for the loop). This would save a TON on small edits that many PRs require, including any additional comments that people might want to add to code that come up during PR...modern PRs is where context goes to die.

<comment><AUTHOR> We went ahead with integration with providers like GitHub and GitLab to have these checks in a central place as it is the easiest way for a team to adopt a tool like ours. Also, just having a local or IDE plugin doesn't ensure these issues never make it to trunk unless everyone in the team follows it strictly.

That said, for the convenience of developers, we're working on the ability to run the analysis and the fixes using our CLI. [1] This opens up doors to use the CLI and build IDE plugins in the near future.

[1] [https://github.com/deepsourcelabs/cli/issues/15](https://github.com/deepsourcelabs/cli/issues/15)

</comment></comment><comment><USER10> There's a better solution: use open-source cli tools that do just that!

1\. 520 Python checks? Use `wemake-python-styleguide` (wrapper around flake8) that has bigger amount of checks: [https://github.com/wemake-services/wemake- python-styleguide](https://github.com/wemake-services/wemake-python- styleguide) There's also `pylint` with a set of awesome checks as well.

2\. Type checking? Use `mypy`: it just a single command!

3\. Autofixing? Use `black` / `autopep8` / `autoflake` and you can use `pybetter` to have the same ~15 auto-fix rules. But, it is completely free and open-source

I don't like this whole idea of such tools (both technically and ethically):

\- Why would anyone want to send all their codebase to 3rd party? We used to call it a security breach back in the days

\- On moral side, this (and similar) projects look like thin wrappers around open-source tools but with a monetisation model. How much do these companies contribute back to the original authors of pylint, mypy, flake8? Ones who created and maintained them for years. I will be happy to be wrong here

<comment><AUTHOR> > There's a better solution: use open-source cli tools that do just that!

We do not deny that you can't run the open-source tools locally. Be it one line command, or be it setting up pylint or flake8 with dedicated configurations. DeepSource is a tool meant to eliminate the need to set up all those open source tools locally or in your CI pipeline. So that you don't need to

\- Fish for issues amongst hundreds of lines of logs in the CI

\- Figure out and update linter config to remove duplicates and false positives (for ex: Bandit throws errors like `assets statement used` in a test file — which is a false-positive. Bandit doesn't know that it is a test file by default)

\- Some issues needed better description of why is that an issue, for ex: why should default file permissions be 0600? Justification on why is it necessary,.

\- By default on every commit or pull request, linters run on all the files.

\- If there are issues that occur in say 50 places, one have to manually fix it.

> 1\. 520 Python checks? Use `wemake-python-styleguide` (wrapper around > flake8) that has bigger amount of checks: [https://github.com/wemake- > services/wemake-python-styleguide](https://github.com/wemake- > services/wemake-python-styleguide) There's also `pylint` with a set of > awesome checks as well.

Our focus at the moment is not on style issues. In fact, amongst the categories of issues we raise (anti-patterns, bug-risks, performance, security, style, documentation), style issues are the most debated on by our users as it is really subjective. We're thinking of removing style issues by default (as an opt-in) and are working on running formatters like `black`, `yapf`, .. with a single line config in `.deepsource.toml`. Our analyzer team actively adds custom rules which you don't get from the open-source tools. The following issues for example:

\- Raising another exception when `assert` fails is ineffective. For ex: `assert isinstance(num_channels, int), ValueError('Number of image channels needs to be an integer')`

\- If the condition would not be satisfied, user would be expecting a `ValueError`, but this would be raised: `AssertionError: Number of image channels needs to be an integer` which should be

\- `yield` used inside a comprehension (which breaks code in Python 3.8)

\- Write operation on file that is opened in read-only mode

\- I/O detected on a closed file descriptor

> 2\. Type checking? Use `mypy`: it just a single command!

Sure. If one prefers running it locally (or) as part of their CI. But if you already use DeepSource to flag issues, it can be enabled by a single line in .deepsource.toml file.

> 3\. Autofixing? Use `black` / `autopep8` / `autoflake` and you can use > `pybetter` to have the same ~15 auto-fix rules. But, it is completely free > and open-source

We are working on adding support for autopep8, black and autoflake in coming weeks. They mostly auto-patch stylistic issues [1]. Thanks for letting us know about pybetter. It looks like a great tool and fixes ~9 issues [2]. DeepSource's autofix aim is to fix more than 3/4th of issues we detect and we detect 522 issues in our Python analyzer. We have dedicated engineering team actively working on the analyzers. As of today, following are some of the issues our Python analyzer can autofix (which I couldn't find it among the open-source tools):

\- No use of `self`

\- Usafe of dangerous default argument

\- Module imported but unused

\- Function contains unused argument

\- Debugger import detected

\- Debugger activation detected

\- Unnecessary comprehension

\- Unnecessary literal

\- Unnecessary call

\- Unnecessary typecast

\- Bad comparison test

\- Empty module

\- Built-in function `len` used as condition

\- Unnecessary `fstring`

\- `raise NotImplemented` should be `raise NotImplementedError`

\- `assert` statement used outside of tests

Same goes with Go and other analyzers we support.

> I don't like this whole idea of such tools (both technically and ethically): > > Why would anyone want to send all their codebase to 3rd party? We used to > call it a security breach back in the days.

We follow strict security practices [3]. In a gist, 1) We do not store your code, 2) Source code is pulled in an isolated environment that has no access to any of our internal systems or the external network, 3) As soon as the analysis is completed, the environment is destroyed and all logs are purged. Also, there are many tools that developers use everyday (Travis CI, Circle CI, GitHub) where the source code is sent to the cloud — I don't think it is accurate to call it a security breach. That said, we have on-premise setup of DeepSource in the roadmap. We're working on SOC 2 Type 2 compliance as well [4].

> On moral side, this (and similar) projects look like thin wrappers around > open-source tools but with a monetisation model. How much do these companies > contribute back to the original authors of pylint, mypy, flake8? Ones who > created and maintained them for years. I will be happy to be wrong here

We have kept the tool completely free to use for open-source projects. We've also partnered with GitHub Education and made it free for students. We're an early stage company trying to build a business in automating objective parts of code review and making it easier for every developer to adopt and use static analysis. With all transparency, we had plans to sponsor open-source projects but got sidetracked due to various reasons. We will be backing some of the open-source projects, in next couple of weeks.

[1] [https://gist.githubusercontent.com/jaipradeesh/6ad8404fef253...](https://gist.githubusercontent.com/jaipradeesh/6ad8404fef253547ec8ca9b7fd187938/raw/f34ebfde7933b9cc7f1015e0b9176d1eabaccc64/tmp.md)

[2] [https://gist.githubusercontent.com/jaipradeesh/b8a0e6b526f73...](https://gist.githubusercontent.com/jaipradeesh/b8a0e6b526f73583cd95f46e2b440b86/raw/2163e83c4382fc7bdb52f9c5c189f88143dd1297/gistfile1.txt)

[3] [https://deepsource.io/security](https://deepsource.io/security)

[4] [https://vanta.com/guides/vantas-guide-to- soc-2](https://vanta.com/guides/vantas-guide-to-soc-2)

</comment></comment><comment><USER11> So our CI pipelines are always set up so that failed linting means blocked merge capability. Your PR isn't ready for review if it's failing rubocop for example. Do you intend to integrate your tool into this type of workflow but by making the lint issues apparent via comment on the PR in GitHub vs in the CI?

<comment><AUTHOR> DeepSource integrates with GitHub checks [1] and via the dashboard, you can select the issue types (anti-patterns, bug risks, performance and security issues, style, type checks and documentation), which when detected, will cause analysis runs to fail and pull requests to be blocked.

[1] [https://pasteboard.co/IZfSThC.png](https://pasteboard.co/IZfSThC.png) [2] [https://pasteboard.co/IZfT8uw.png](https://pasteboard.co/IZfT8uw.png)

</comment></comment><comment><USER12> Cool! Can you provide some real world examples of issues you flag? I poked around on your site and didn't see any.

<comment><USER6> A few issues from our Python analyzer:

* Dangerous mutable default argument passed in functions

``` def some_func(arg=[1,2,3]):

        ...

```

which should be

``` def some_func(arg=None):

        if arg is None: arg = [1,2,3]
        ...

```

* `yield` used inside a comprehension (which breaks code in Python 3.8)

* file opened with the "r" flag, but a write is attempted on the file

* i/o detected on a closed file descriptor

* providing an unexpected keyword argument in a function call

</comment></comment><comment><USER13> Is there a list of the open source static analysis tools that you are using? Do you have any proprietary tools you have written?

</comment><comment><USER14> When you offer support for C++, we'll talk. More challenging to parse and analyze, of course.

<comment><AUTHOR> Sure. I've left you an email.

</comment></comment><comment><USER15> Congrats! Any plans to add support for more languages?

<comment><USER6> Ruby is already in beta, stable release in the next 3-4 weeks. Next up is JavaScript. Rust, Java, and PHP are further down the line.

<comment><USER16> How does it compare to static analysis as rubocop actually does. Especially in who decides what anti-patterns are

<comment><USER6> For our analyzers, we actually do use existing static analysis behind the scenes in addition to our custom checkers that we write by hand. So our Ruby analyzer, which is in beta at the moment, does use Rubocop behind the scenes. We're working towards the stable release of Ruby analyzer which uses augmentations to remove false positives and decrease the noise — since guaranteeing less than 5% false positives is one of the primary values that DeepSource adds. As the anlayzer moves towards stable, we'll add custom issues to it.

The general categorization of anti-patterns is based on the consensus of the community around the language, and also some obvious things based on objective reasons. Although we understand that everyone has their own flavor of conventions — so it is very easy to triage and ignore specific issues in DeepSource.</comment></comment></comment></comment>


Ask HN: Need help from outside in establishing initial equity picture - <AUTHOR>

I am wondering if there is such a thing as a neutral 3rd party service that provides an outside assessment to help a team that is ready to incorporate come to a decision on equity division?
It's a scenario where there are different levels and types of input, where it's very positive, and the general spirit is it'd be good to get a neutral/outside take on how to set things up rather than haggle or negotiate internally.
Been trying to get an answer via Google search but have not able to make headway. <comment><USER2> > "where it's very positive"

I don't understand what you mean there. The founders are feeling good about things?

I realize it's probably much more simplistic than what you're looking for, but I did run across this the other day: [http://foundrs.com/](http://foundrs.com/) It's a simple calculator for dividing equity. Maybe good enough to use as a starting point?

Or you could just say fuck it and divide things evenly: [https://web.archive.org/web/20131109064121/http://answers.on...](https://web.archive.org/web/20131109064121/http://answers.onstartups.com/questions/6949/forming- a-new-software-startup-how-do-i-allocate-ownership-fairly/23326)

<comment><AUTHOR> Thanks for the tips. I have the seen the calculator for equity. I am just curious if more robust services exist?

I meant "positive" in exactly the way you suggested.

</comment></comment><comment><USER3> If the process involves haggling and negotiating then it is a game between founders rather than a business decision. Sure it was someone's idea and someone wrote the code and someone picked up the pizza and made the coffee and you could dig through the past and assign values to all those things. It's totally fucking stupid but you could still do it.

What matters is not how you got here but where you will go. What matters is not how much work you have done but what work each of you is going to do. If you pivot are you going to claw back equity from the idea guy? When the code base is rewritten in Go to support that pivot is the programming guy losing stock?

Allocate equity based on pots of coffee made [one of you will like this idea] or divide it equally and focus on trying to make so much money that an additional 5% equity split doesn't matter.

Good luck.

</comment><comment><USER4> [http://www.backofanapkin.co.nz/](http://www.backofanapkin.co.nz/) provides some talking points (and an agreement if you want it) that you need to decide on upfront - even if you're going to incorporate later on.

</comment><comment><USER5> just make sure stuff is vested over time so people aren't sucking up equity that they really didn't earn.</comment>


Good learning material – JAVA, Spring - <AUTHOR> Hi! I graduated college and am two years into Software development and would like to keep up with the latest technologies/ hone my skills. What books/learning materials do you guys suggest for following topics:
1. Spring 2. Springboot 3. JAVA 4. Object Oriented programming 5. Mongodb 6. Microservices 7. RESTful webservices 8. Any general books all programmers must own<p>Thanks :) <comment><USER2> Oh wow - this is actually a really big and important question.

The things you've listed sort of split into two separate categories: Paradigms/Architectures, and specific tools.

I'd focus on the Paradigms and Architectures first - those are the skills that will be portable across tech stacks and will be useful for a longer period of time.

For OOP, I actually enjoyed Head First Object Oriented Analysis and Design [1]. The Head First books aren't for everyone, but I like they way they encourage you to do exercises to help reinforce what you've learned.

For RESTful services, I found Roy Fielding's original PhD dissertation on REST[2] to be quite helpful for a conceptual overview. It's a long read, but I enjoyed it.

For Spring and Spring Boot, I've found the official Spring guides[3] to be better than any of the books I've read. So many Spring books seem to go out of their way to try to be as long as possible. The guides, on the other hand, tend to be short and to the point.

As for general books...the one I always circle back to is Structure and Interpretation of Computer Programs[4]. I found that once you've worked through it, so many aspects of programming just make more sense. Lots of people find it a difficult book to work through, but I've found that the more times I revisit the book over the course of my career, the more helpful it is. Every time I read it I seem to have an 'aha!' moment I hadn't experienced previously.

[1] [https://www.amazon.com/Head-First-Object-Oriented- Analysis-D...](https://www.amazon.com/Head-First-Object-Oriented-Analysis- Design/dp/0596008678)

[2] [https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...](https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf)

[3] [https://spring.io/guides](https://spring.io/guides)

[4] [https://mitpress.mit.edu/sicp/full- text/book/book.html](https://mitpress.mit.edu/sicp/full-text/book/book.html)

<comment><AUTHOR> Wow! Will definitely look into those! thankyou!

Yes the two categories were intentional, because i want to build up a strong base, as well as get better at what i am already doing.

</comment></comment><comment><USER3> a.) On java - one hour talk but good:

* How To Design A Good API and Why it Matters [https://www.youtube.com/watch?v=aAb7hSCtvGw](https://www.youtube.com/watch?v=aAb7hSCtvGw)

b.) General code structure - dont to read it cover to cover unless you like to, you will die of boredom, but definitely have a look in library. It will help you to think about code structure right way.

* Refactoring: Improving the Design of Existing Code * Code Complete

c.) Object Oriented Programming

* Design Patterns: Elements of Reusable Object-Oriented

The three books I recommended are older, but not much changed in basics of object oriented programming. They are well readable. I would also recommend to read something on functional programming, mostly so that you see another approach too and thus wont go too far with object design where it does not suits.

d.) 8.) I read awesome book on estimations, I really really hope it is this one:

* Software Estimation: Demystifying the Black Art

tldr: There is difference between negotiation and estimation, make sure you know which you are doing. Split it into smaller tasks and then estimate minimum, maximum and most likely. Then calculate (min+4*likely+max)/6\. Surprisingly, it works and is faster then do one estimate. It is also more precise then anything else I tried. I really hope I shown you right book.

e.) On Spring and rest, I would recommend to read documentation and write own code. I don't recall a book that would blow my mind, so I guess any will do.

f.) For general "latest tech" learning, I like [https://dzone.com/](https://dzone.com/) site. There are mostly techie tech articles - they are not news site like hacker news or arstechnica. They have "zones" for different interests, java zone is here: [https://dzone.com/java- jdk-development-tutorials-tools-news](https://dzone.com/java-jdk-development- tutorials-tools-news) . Pick up zones and make a habit of reading one article a week or something like that.

<comment><AUTHOR> Bookmarked :) Thankyou!

</comment></comment><comment><USER4> Apart from the resources already mentioned (the official Spring guide in particular alongside the tutorials) Mkyong.com is a terrific tutorial site for everything Java and Spring Boot: [https://www.mkyong.com/](https://www.mkyong.com/)

</comment><comment><USER5> Jhipster is a great tool for generating starter Spring Boot projects. Here is a recent Pluralsight course that will walk you through using it [https://www.pluralsight.com/courses/scaffolding-spring- boot-...](https://www.pluralsight.com/courses/scaffolding-spring-boot-and- angular-with-jhipster)

<comment><AUTHOR> Awesome thanks!

</comment></comment><comment><USER6> [https://github.com/Developer-Y/all-things- java](https://github.com/Developer-Y/all-things-java)

It doesn't has lots of stuff on Spring boot/Microservices but that can be updated later on. For MongoDB you should check Mongo's free online course for Java developers.

</comment><comment><USER7> For Java:

Effective Java by Joshua Bloch.

For Spring:

Pro Spring 3 by Harrop and Ho was useful to me in getting a basic CRUD application running.

<comment><USER8> Keep in mind too that Effective Java was recently updated/rewritten a long time after the second edition was printed. So to the OP make sure you look at the third edition and not the more linked to/blogged about/higher visibility in google second edition.

</comment></comment><comment><USER9> That depends, are you interested in a particular technology or skill? Please be more specific.

<comment><AUTHOR> Thanks! I updated my question

</comment></comment><comment><USER10> Lesson 0: It's "Java", not "JAVA".

</comment><comment><USER11> I use baeldung.com for spring tutorials a lot</comment>


Please review my HN November app - <AUTHOR> http://www.previouslook.com/

<comment><USER3> I wish there was a way to enter MY site and have it regularly take a snapshot weekly, monthly, yearly. That way, a year from now I could have a record of what things looked like and what happened over that year, without having to think about it. I would pay a few bucks for a system that did that. Sort of like a personal internet archive.

<comment><AUTHOR> Allowing anyone to define the crawling policy and snapshot any site is in the plan. I need to build up the UI for the backend process to crawl and transform the webpages. I'm building the backend tools as I go along. So far it's just a proof of concept with couple sites defined. Once the tools are ready, I'll open the backend up.

</comment></comment><comment><USER4> I was very impressed to see the left and right arrow keys work "as expected" when tested. To be specific, the keys on the keyboard.

Unfortunately, the arrowish >>> and <<< links are broken. When the page first loads, it give the most recent snapshot, which is nice. The problem with the arrowish links is they do not allow you to go backwards in time, but do allow you to go forward in time, hence causing an error since the future hasn't happened yet. ;)

<comment><AUTHOR> Thanks for feedback! All credits of the arrow keys working go to JQuery. :)

The <<< and >>> are my poorman's UI implementation of left and right arrows. It seems the prefetching has some problem when going left and right too fast. I'm turning prefetching off and re-deploying the app. It'll be up in a moment.

<comment><USER4> hmmm... Of course you know your code far better than I do, and I'm just guessing here, but on the omega (most recent snap), the 'forward-in-time' arrowish >>> links existed when they should not exist. At the same time, the 'backwards-in-time' arrowish links <<< did not exist (i.e. you can see the characters but they were not actually links).

Since from the most recent snapshot, the only option should be to go backwards in time (rather than forward), it seems you have your logic reversed somewhere.

<comment><AUTHOR> Can I ask what browser, version, and platform are you using? I've tested it on Firefox 3.6, Opera 10, and IE 9 on Windows, and the <<< and >>> seem to work. When you hover the mouse on top of the <<< characters, is there a underline showing up?

There's no enabling/disabling of the <<< and >>> links, (though it might be a good idea to show/hide depending on the current snapshot). They are just anchor with href=#, with Javascript to handle the mouse click. The links should always be there.

There are CSS styles modifying the anchor links. Here're the CSS I use for the A links.

a:link { text-decoration:none; }

a:visited { text-decoration:none; }

a:hover { text-decoration:underline; }

The underline only shows up when the mouse is hovering on the links.

<comment><USER4>
      $ uname -a
      OpenBSD lynx.foo.bar 4.7 GENERIC#642 i386
      $ firefox -v
      Mozilla Firefox 3.6.3, Copyright (c) 1998 - 2010 mozilla.org
      $ date -u
      Tue Nov 30 08:21:05 UTC 2010

Yes, I need to upgrade this particular box.

Tested with you "HackerNews Newest" snapshot set.

As previously stated, only the 'forward' link appeared, and the 'back' was just plain characters rather than a link, when the omega (first snapshot) was initially loaded. Yes, I noticed the hover.

Since you mentioned making changes and rebooting your app/site, I just gave it another try and the behavior has changed. Now both the 'back' and 'forward' links exist on omega (most recent snap). Both of the "Previous Time Slot" and "Previous Batch" links work now.

The only thing left to fix is the handling of 'forward' links ("Next Time Slot" and "Next Batch") and the 'forward' key-press (right arrow key) when already displaying omega (most recent snap).

On the other hand, if you have some magical way to display snapshots of stuff before it happens, then you _really_ need to start tracking stock symbols. ;-)

Most importantly, congratulations on delivering your November app. It is very nicely done.

<comment><AUTHOR> I'll set up OpenBSD VM to test it out. That's very detail bug report. Thanks!

</comment></comment></comment></comment></comment></comment><comment><USER5> Very cool. I'd definitely pay for a service to give me a history of my web apps over time. I'm often asked when we implemented a feature and have to dive back into (poorly documented) subversion commits. This would be much easier in many cases.

Would love to hear the storage/cost requirements for archiving a site over, say a year. (I guess that would depend on archive frequency).

<comment><AUTHOR> So far the storage is minimal since it only archives one page over time. It also transforms the page to extract only the stuff it needs to display, cutting down on the size further. Archiving a whole site with all the media (pic/sounds/videos) would take more storage. But disks are cheap these days. It shouldn't be too bad.

I'll look into that. Thanks.

</comment></comment><comment><USER6> Nice idea.

I know it's early days but the header and the takes that reads "Previous Look | web page snapshots over time" doesn't seem a very high resolution i.e. the text looks a little jagged on Chrome.

This is petty I know but it's the first thing I noticed.

Functionality wise though, nice work :D

<comment><AUTHOR> Wow, I actually spent some time to add the text-shadow and etched effect to the letters to make them blur. Didn't realize it invokes the opposite reaction. My design sense sucks. Should have followed the KISS principle. Thanks for the honest feedback.

<comment><USER6> It might just be my monitor, I'm viewing this from work on an XP machine - <USER2> it might just be ClearType not working properly.

</comment></comment></comment><comment><USER7> I liked it. The logo text in the header does not link to home page. Is it deliberate?

<comment><AUTHOR> Thanks for the feedback. No, the logo text doesn't link was an oversight. The logo image links back to home; I thought that was enough. I'll add the link to the logo text as well.

</comment></comment><comment><USER8> Good idea, good functionality but get a designer on this ASAP. To users, design of the app IS the app.

One quick fix on the front page - "What does it do" and "Start Exploring" should have matching capitalization schemes.

<comment><AUTHOR> Thanks for noticing the capitalization. I'll fix it. A designer probably will take it up to another level, but I can't afford one for now. :)

</comment></comment><comment><USER9> Looks like fun. I would like to see a play button, like etherpad. Also live scrubbing would be nice: as the user scrubs the timeline it could show the pages, rate-limited to 10Hz or something.

<comment><AUTHOR> Playing it forward or backward is an excellent idea, like a VCR. I'll try to put it in. Live scrubbing while sliding was intentionally turned off. I figured it doesn't let people read the content while flying over the pages, while hitting the server with each page. It mainly shows a visual effect without real benefit. But if people really want it, I can put it back on.

</comment></comment><comment><USER10> In Chrome 7.0.517.44 on OS X the green headings partially overlap the elements of the page above them.

<comment><AUTHOR> Thanks. I'll try it out in Chrome to fix it.

</comment></comment><comment><USER11> that is an awesome way to look back on past post on HN. I will use. Thanks</comment>


Be Careful with Python's New-Style String Format - <AUTHOR> http://lucumr.pocoo.org/2016/12/29/careful-with-str-format/ <comment><USER2> For user defined templates, using string.Template() is a good alternative because it does not do multi-level attribute lookups. The single mapping lookup is safer. Also, the syntax is simpler, making it more suitable for exposure to end users and making it less hackable.</comment>


Intelligent resizing of images - <AUTHOR> http://www.ohgizmo.com/2007/08/21/smart-image-resizing-cuts-the-useless-out-of-your-pics/ Check out this new algorithm for resizing images. <comment><USER2> <http://news.ycombinator.com/item?id=45073>

Welcome to news.ycombinator, you'll like it much more here after you start drinking the Kool Aid.</comment>


5 Common Mistakes in Building a Paywall, Explained by Example - <AUTHOR> https://medium.com/@klyburke/5-common-mistakes-in-building-a-paywall-explained-by-example-4573f2c60af <comment><USER2> Biggest mistake is to make buzz feed articles that people spam all over hacker news so we end up black listing them.</comment>


Go stack traces and the errors package - <AUTHOR> http://dave.cheney.net/2016/06/12/stack-traces-and-the-errors-package <comment><USER2> The fact that you need a third party non-standard package just to reliably get error stacks is ridiculous.

What's worse, is this solution doesn't solve random third-party packages you depend on all that much since they'll still use the utterly useless std- library error package or their own variation which won't necessarily be compatible.

<comment><USER3> What bothers me a lot more is that Go has somehow managed to get a trivial but crucial thing totally wrong: Some errors can only be identified by value and others can only be identified by type.

There is no general and reliable way to handle specific types of errors.

And there is no way to add instance specific information to errors in a later version of a package, because that would require using an error type instead of (or in addition to) the existing well known error value, which breaks callers.

<comment><USER4> > And there is no way to add instance specific information to errors in a > later version of a package, because that would require using an error type > instead of (or in addition to) the existing well known error value, which > breaks callers.

Yes you can. Errors are interfaces, not values. As long as you define an Errror() method your struct behaves as an error, but it can have anything a struct has, such as specific information.

You should read Dave's previous presentation ([http://dave.cheney.net/paste/gocon- spring-2016.pdf](http://dave.cheney.net/paste/gocon-spring-2016.pdf)) to understand a bit more about what's _already_ possible today and why Dave's package makes it easier.

<comment><USER3> Interfaces don't help in this case. Say you have a package called net:

      var Error = ...

      func Get(url string) (result, error) {
        if ... {
          return Error
        }
      }

Users of your package would do something like this

      r, err := net.Get("http://example.com")
      if err == net.Error {
        //handle this particular error
      }

What if you decide that there are in fact different types errors or you want to return an error code with each error? How would you do that?

<comment><USER4> You should read Dave's presentation again. Asserting for a type is the wrong way to do it, your library should instead provide a helper for the specific parsing you want to do.

So if you want to know if this error is temporary, you should have this, _inside the net package_ :

      func IsTemporary(err error) bool {
        // specific parsing
      }

Similarly, if you _really_ want an error code:

      func ErrorCode(err error) int {
        // a type assertion, which is fine because we're inside the net package
        v, ok := err.(ErrorWithStatusCode)
        if ok {
          return v.ErrorCode
        }
      }

(Note that in the standard net/http package, the result of an http call is inside the result, never in the error that is returned, whatever the status of the http call is)

Basically your package should give all tools so that callers can take a decision without knowing about internals of the package. Knowing the exact error code is probably not what a caller wants; what they probably want to know is whether the error is temporary or fatal, if they can retry with a chance of success, if they can take counter-measures and if they can't alert the user.

<comment><USER3> I think I have read everything Dave Cheney has ever written about errors. But you misunderstand what I'm saying.

The standard library is already littered with error values defined on the package level. Many third party packages emulate that approach.

Once you have done that in package, there is no way to change it. You cannot add function call specific data to an error after the fact. There is no way to implement an IsTemporary(error) function once you have clients that compare any returned error to a package level singleton using ==.

 _> Knowing the exact error code is probably not what a caller wants_

I had that need many times. For instance, I needed to get the SQLSTATE from database errors. There is a huge number of SQLSTATE codes and interpreting/classifying them can't be the job of a data access package or even a DBMS specific driver library.

Also, how would a networking package know what I consider temporary? Some protocols like HTTP specify some errors to be temporary, but that may not coincide with what I'm willing to retry or not retry.

</comment></comment></comment></comment></comment></comment><comment><USER5> Having been writing Go for 4 years now, I can say that Dave Cheney's package is exactly what I've been looking for.

The thing that really sells it to me is the being able to wrap the error when necessary with errors.Wrap and find the underlying cause with errors.Cause. I've yet to experiment with the new formatting `%+v` but I can see that coming in useful too.

There have been earlier attempts at something similar (eg [https://github.com/juju/errors](https://github.com/juju/errors)) but none with the same clarity of thought.

So thanks for a great package Dave and for taking the time to whittle it down into the simplest, most elegant thing.

<comment><USER6> We've been doing this via an in-house errors package for a while. It does other things, like log request ID with the error for tracing and whatnot, and uses a bit of code adopted from panicparse [0] to print pretty, easy-on-the- eyes, quickly-parsable stack traces.

Honestly I don't know why stack traces aren't formatted for quick parsing. Many thanks to maruel [1] for the inspiration.

[0] [https://github.com/maruel/panicparse](https://github.com/maruel/panicparse)

[1] [https://github.com/maruel](https://github.com/maruel)

</comment></comment><comment><USER7> I've been using my own errors package for a while to address a different issue with errors when building RESTful APIs or web applications... when the error occurs, the code that touches it first best knows the HTTP status code to ultimately return.

My package in it's entirety is:

        package errors

        const ErrUnknown = 0

        type RESTError struct {
        	HTTPStatus int    `json:"-"`
        	Code       int    `json:"code,omitempty"`
        	Message    string `json:"error"`
        	Err        error  `json:"-"`
        }

        func (e *RESTError) Error() string {
        	return e.Message
        }

        func New(status int, code int, message string) *RESTError {
        	return &RESTError{HTTPStatus: status, Code: code, Message: message}
        }

Doc comments removed just to show the code and nothing else.

When those errors finally get back to my web handlers, a standard renderError wraps all errors:

        func renderError(w http.ResponseWriter, err error) int {
        	if e, ok := err.(*errors.RESTError); ok {
        		return render.JSON(w, e.HTTPStatus, e)
        	}

        	e = errors.New(http.StatusInternalServerError, errors.ErrUnknown, err.Error())
        	return render.JSON(w, e.HTTPStatus, e)
        }

I handle all errors as soon as possible and then immediately assign the HTTP status code that should be returned, the error code to enable an external system to look up the error (without string parsing), a sanitised error message (to allow devs to get an idea without looking up the code) and I do put the original error in the Err so that my log files can contain the raw underlying error.

It effectively acts as a map between internal errors, and external communication of errors, and allows the place where the error occurred to say "this HTTP status". And because the Err is never stringified I am comforted that internal sensitive data (this is a billing system and unsanitised data should never be leaked even via error messages) does not get leaked.

That's my goal, to handle the error in the way that allows it to best communicate to:

1\. HTTP clients via the status

2\. Developers via an error code and sanitised message (which they can use to communicate to users)

3\. SREs via detail in the secure logs

I found the native errors nice, but not the best for dealing with my 3 audiences.

<comment><USER8> Hah, this is very similar to the one I use within my apps.

type AppError struct { Code int Message string InternalMessage string Time time.Time HttpCode int }

All my errors are handled in a http handler function. Before that these errors are produced in any functions called by my handler functions.

I concatenate in to the InternalMessage var any error message I want to log, basically anything I want to show an admin. The message tag will have anything I want to show a user. Normally separated by a semicolon.

Because of this I can give good errors to my users, and I have enough information when something goes wrong.

The only negative might be that, the internal error logs are a bit verbose.

<comment><USER8> oops. My Bad

the code above should be

      type AppError struct {
        Code int
        Message string
        InternalMessage string
        Time time.Time
        HttpCode int
      }

</comment></comment></comment><comment><USER9> I don't follow the logic of avoiding error types.

If I'm calling `foo.Bar()` directly, I already have a direct dependency on package `foo`, so what difference does it make to have another one to get `foo.BarError`?

If I'm calling `foo.Bar()` indirectly, then it's true that checking `foo.ErrorType` introduces a novel dependency upon `foo`, but it's equally true that:

a) my direct dependency is frequently going to check and wrap that error in some other type anyway, and

b) I can still use the interface trick that Dave describes to avoid a dependency on `foo`.

I don't see why forcing callers to declare helper interfaces every single time they want to inspect an error is preferable to them only having to do that as a rare workaround.

</comment><comment><USER10> There are two types of errors: the ones you log, and the ones you report to the user.

The difference is that the latter has to be translated to be useful (even when your user understands english).

<comment><USER11> What about the ones you retry?

<comment><USER10> This part was covered by Cheney already, isn't it?

</comment></comment></comment><comment><USER12> Link below from google web cache since website is unavailable

</comment><comment><USER12> [http://webcache.googleusercontent.com/search?q=cache%3Arobot...](http://webcache.googleusercontent.com/search?q=cache%3Arobotwealth.com%2Fmachine- learning-financial-prediction-david- aronson%2F&oq=cache%3Arobotwealth.com%2Fmachine-learning-financial-prediction- david-aronson%2F&aqs=chrome..69i57j69i58.1735j0j4&sourceid=chrome&ie=UTF-8)</comment>


Ask HN: If your startup ever goes public, what stock symbol would you use? - <AUTHOR>

Would you use one that somehow spelled out your company name(Google - GOOG) or would pick one that spelled out your product(SUN - JAVA) or would you pick one that spelled out your niche(AVIS - CAR) or something completely random? <comment><USER2> Before you go public, or selling for that matter, make sure your startup is not your life's work. My first project was one I worked on since I was 16 and sold it when I was 24. Granted, it wasn't a startup but a software product, it was to me a combination of high school, college and graduate school. When I sold it and signed the ridiculous non-compete papers, I had NOTHING else to work on. Even the much taunted liberal arts PhDs get to keep their titles; I kept nothing. (sure, I was happy to sell it by then, because I was burned out, but it might have been better to delay the negotiations until I was in a better emotional and financial state and was optimistic about the future.)

I know this is tangential to the topic at hand, but had to air my grievances to warn someone else who might be tying their startups with their personal identities.

</comment><comment><USER3> FSCK or ARGH would be funny symbols.

Honestly, I wouldn't care much about what it was called at that point. My eyes would be big glazed-over dollar-signs.

</comment><comment><USER4> I prefer to use the first choice, (Google - GOOG) or (Microsoft - MSFT) as it's unique and represent my company

</comment><comment><USER5> WEB - not sure if its available

<comment><USER5> or WWW

</comment></comment><comment><USER6> EXC (granted I have yet to check whether it exists)</comment>


Guilloches (2008) - <AUTHOR> http://ministryoftype.co.uk/words/article/guilloches/ <comment><USER2> Here's a nice way to play with the parameters: [https://www.desmos.com/calculator/3wrid37iir](https://www.desmos.com/calculator/3wrid37iir)

</comment><comment><USER3> Made the front page after nearly 7 years: [https://news.ycombinator.com/item?id=273054](https://news.ycombinator.com/item?id=273054).</comment>


Swiftype (YC W12) site search added to Mixergy - <AUTHOR> http://mixergy.com/introducing-our-new-awesome-search-and-the-story-behind-it/

<comment><USER2> Good stuff. Mixergy was awful when it comes to searching for something. This should make it a lot better.

</comment><comment><USER3> Nice work, Quin and Matt!</comment>


Producing Open Source Software (2017) - <AUTHOR> https://producingoss.com/ <comment><USER2> > Producing Open Source Software > How to Run a Successful Free Software > Project

I feel like mixing these terms up might put off RMS, amongst others?

<comment><USER3> It is probably easier to list the things that _won't_ put off RMS.

God forbid you use the DOM[1] in your JS!

[1] [https://www.gnu.org/philosophy/javascript- trap.html](https://www.gnu.org/philosophy/javascript-trap.html)

<comment><USER4> I don't see your point. That article isn't against the use of JavaScript, it's against non-Free software.

Stallman's position is that the principles of Free Software apply to non- trivial JavaScript code. That seems reasonable enough. His definition of _non- trivial_ JavaScript is such that any JavaScript that modifies the DOM, is necessarily considered non-trivial. Again, seems reasonable enough.

If we want an example of RMS being unreasonable, we need only look as far as the Q&A after one of his talks, where he can generally be relied on to bitterly snap at an audience member for some inexact use of terminology, rather than gently clarifying before answering.

</comment></comment></comment><comment><USER5> If you find something that can be improved — you can contact the author, Karl Fogel, there's a "Make a suggestion or comment on the book" link a bit down (not so easy to find).

I'm going to send him a message — the book recommends dead-link Q&A forum software, whilst I've built something new & up-to-date.

<comment><USER6> Yeah, I've got some cleanups to that section pending. Looking forward to your suggestion, KajMagnus!

Best regards, -Karl Fogel

<comment><USER7> If one was interested in buying a print copy, will those be generally available (lulu?) after the campaign ends?</comment></comment></comment>


Ask HN: 2 sided global platforms – how are you handling sales tax? - <AUTHOR> Assume you are a platform connecting buyers and sellers of service globally. Lets say this is a marketplace for graphic design service.
Handling sales tax appears to be very hard:
* EU wants you to charge the buyer at the point where the buyer is located and rates differ by country. Are there any companies offering APIs for this?
* Each state in the US has its own rules. There are companies like TaxJar offering APIs to east this pain. Can any users comment on their experiences with similar services?
* Repeat for literally every country in the world.
* But charging the right amount of tax appears to be the easier part of the problem. Now assume you have charged sales tax/VAT to buyers in various countries at the correct rate. At the end of the year you now supposed to make payments to the tax authorities in each of these countries? And each state in the US?
How are you solving this?
Thanks. <comment><USER2> We (based in Europe) use [https://quaderno.io/](https://quaderno.io/) for the tax calculation, reporting, invoice creating and sending. For example they collect the proofs the EU needs, like country of user, country of bank, country of transaction (IP address). They're not a payment provider but connect to others, we use Stripe. I recommend them. Not sure about US states, that doesn't apply to us.</comment>


Master/Slave Terminology Was Removed from Python Due to Association with Slavery - <AUTHOR> https://motherboard.vice.com/en_us/article/8x7akv/masterslave-terminology-was-removed-from-python-programming-language <comment><USER2> I agree.so ,we should delete the word from dictionary,sue those who dare say the word,spy on everyone to find out who even dare to think about this word.

</comment><comment><USER3> Same with computers

"Los Angeles officials have asked that manufacturers, suppliers and contractors stop using the terms 'master' and 'slave' on computer equipment, saying such terms are unacceptable and offensive."

[http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut/](http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut/)

</comment><comment><USER4> The word kill is also pretty offensive. Police kill many people of color daily. Slaves were killed by their owners. I think more inclusive verbs are disable or quiesce.

</comment><comment><USER5> 1984</comment>


How a nation of junkies went cold turkey - <AUTHOR> http://www.newrepublic.com/article/113051/georgias-war-drugs-how-its-subutex-addiction-ended <comment><USER2> Normally, on topics like this I post under a throwaway. Now, I don't see why I should.

I'm an ex-heroin addict, and am on Suboxone Opiate Replacement Therapy. I've been clean for 9 months, after 6 years of opiate addiction (starting with Oxycodone, and moving quickly to Heroin). I'm 22 years old.

This article has a few factual inaccuracies, which I want to correct.

First: Injecting Suboxone is NOT safe. Not even close, especially with the method described in the article: unless you are a fan of Talcosis (which will kill you), you need to get a micron filter. Even then, it's not worth it. The high is minimal, tolerance builds rapidly, and it's dangerous. There are numerous complications that come from injecting pills, and it's never worth it.

Second, and this is a small nitpick, heroin users don't have "eyes like saucers" - you have eyes like pinpricks. Opiates constrict pupils, not dilate then.

Third, heroin withdrawal IS torture, at least if you have a sizable habit. Yes, Burroughs did say it was "overrated", but I can tell you from experience, it's absolute torture. It's not like fever. It's an entire body ache, down to your very bones; it's your mind crying out for relief. It's something I wouldn't wish on my worst enemy.

Just thought I'd add my two cents.

<comment><USER3> There were a number of annoying factual inaccuracies in the article, particular with respect to heroin:

> ..time-killing properties of opium or heroin, but with none of the > likelihood of it stopping his heart

Opiates do not stop your heart. The notion that every single usage of opium or heroin is like a game of russian roulette, that might stop your heart, is fantasy. Opiates are actually quite safe, as drugs go. It's not until you take far too much or mix them that you are screwed. And that's true of any opiate, prescription or otherwise.

> Heroin kills, and OxyContin, unless badly mishandled, does not.

Basically not true; injected oxy requires no more 'mishandling' than heroin to kill. Both will happily shut down your respiratory system and kill you if you administer too much. Of course one could argue that the pharma is of a consistent manufacture and dosage, whereas one batch of too-strong street opiates could kill someone used to weaker stuff, but the author of this piece seems far too clueless about the subject to be making such distinctions.

Then we have comparison of marijuana's 'addictiveness' to that of opiates. The difference between psychological dependence and physical dependence is one of kind, not degree.

<comment><USER2> Injected OxyContin is worse, actually. Being 2/3rds the strength of heroin, but being in pill form, means you're running the gauntlet with talcosis, and causing other terrible and fatal medical conditions due to the nature of what is put in the pills themselves.

Heroin and pure opiates are actually "safe" as far as drugs go. I'm clean, and even when addicted held down good jobs, earning good money, and no-one was the wiser. My vitals are still perfect to this day.

It's the addiction that gets you, unfortunately.

<comment><USER4> As a child I was once in a english class for people in rehab from heroin. This was Spain in the early 90s and most of them had been addicts fOr more than 10 years. They were definitely affected neurologically, they were like a bit in slow motion and could disengage from their sorroundings quite easily. They were in the last part of the therapy, almost ready to go home, but I can't tell if that was an effect of a substitution therapy( at the time it was methadone), or they had a permanent cognitive damage.

<comment><USER2> Methadone, at least in my experience, really does "zombify" you. It has really pronounced CNS depressant effects. It's basically no different from Heroin in how it affects your state of mind: that's why I personally chose Suboxone as my ORT drug.

<comment><USER5> I've done high-level cognitive activities like programming for 5 years of methadone therapy with little to no problems. I took the GRE on methadone therapy and did better than when I was on no opiates 10+ years ago. Used properly, methadone's side effects can be minimized to almost none in most patients. I tend to get sleepy after lunch, but I honestly can't tell if that's the methadone.

Most of the "zombified" methadone users are way overmedicated, usually because this is the state they are seeking.

<comment><USER2>
      > Most of the "zombified" methadone users are way overmedicated, usually because this is the state they are seeking.

I agree entirely :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Around 1 in 20 people have personalities such that they're prone to addiction, to the extent that it can cause them to make questionable decisions. Drinking, smoking, sex, heroine, gambling, porn, work, party drugs, Subutex, anti- depressants, whatever, you name it. We need to stop prohibiting whatever activity/substance people actually get addicted to because its essentially arbitrary, and start compassionately treating the root psychological causes.

<comment><USER7> _start compassionately treating the root psychological causes_

How? Couldn't limiting access of an addicted person to the substance or activity the person is addicted to be one part of compassionate treatment? What research is there on this?

<comment><USER8> Limiting access to a substance or activity doesn't address the problem, which is the behavior. If the person in question ends up replacing it with a safer substance or activity, that may be somewhat better, but they may instead end up replacing it with something even more dangerous. It's a gamble and it doesn't even address the problem. Blaming inanimate objects for the actions of humans never really helps. It would be better to address the actual humans, their actions, and the causes instead. We just don't know how to do that yet. As a society, we aren't smart enough.

</comment></comment></comment><comment><USER5> As an opiate addict on methadone for 5 years, I have a problem with this article because of several major factual inaccuracies.

First, and most notably, heroin withdrawal, like withdrawal from any opiate worth its cost, is absolute torture. It's ironic that Burroughs was quoted here, since he's written some of the most accurate descriptions of the utter pain of withdrawal. It's far, far more serious than something like swine flu (which I had during the pandemic), and people can and do die from opiate withdrawal on a frequent basis, usually from the accompanying cardiac issues.

Second, having dosed in methadone clinics across this country, I've never seen one with an armed guard, or even an unarmed guard. I've dosed in a clinic in Gary, Indiana, and one in a rough spot near Orlando. Both were clean, safe, well-run places with no guards necessary. In my 5 years on methadone, I've only seen the police called to a clinic on one occasion, when a disgruntled patient got a little verbally abusive toward a counselor. But never physical violence, and never a need for armed guards. It's possible that there is a clinic somewhere that has an armed guard, but saying methadone clinics in general have armed guards is incorrect.

Others with far more experience in issues like this than the writer have commented on other inaccuracies, like the "saucer-like" eyes of heroin users, and the exaggerated desirability of Subutex to IV drug users.

Because of inaccuracies like this, I have to doubt the other "facts" reported in this article. The whole piece seems to have been written to support a pre- existing idea the writer has about drug policy. Good journalists do this the other way around.

<comment><USER9> I've never been near one of these clinics, but is it not possible that 95% of them do have armed guards and the two you went to are in the 5%. Not saying you are or aren't wrong, just that both ways are possible.

<comment><USER2> None that I know of (and go to) in Australia do, mainly because you can dose at any pharmacy that participates in the program.

</comment></comment></comment><comment><USER10> Note to self, never visit Georgia. This is how they did it:

>If you think New York's stop-and-frisk rule is invasive, try Georgia's: Cops can stop anyone at any time for no reason and force him to urinate into a cup. Fifty-three thousand people were stopped on the street in 2007, or about one in 20 of the young men in Georgia.

</comment><comment><USER11> WAY off-topic, but I think this is the first mobile-theme I've seen that renders the site completely unusable on a mobile device. (iPhone 4s - doesn't scroll at all)

<comment><USER12> I was hoping it wasn't just me. I'm using a galaxy s3 and I'm experiencing the same issues.

</comment></comment><comment><USER13> Honestly the cure seems worse than the disease here, if what they were saying about Subutex is true (I'd never heard of it before this article). Heroin is horrible stuff that can easily kill you. For that matter so is alcohol. I really don't see the point of cracking down on something that is displacing far more dangerous drugs.

<comment><USER14> It wasn't displacing heroin. Heroin didn't make a resurgence. Krododil did, but its use was not nearly as prevalent as the use of Subutex was. The point is that the society got a lot safer and more productive after the Subutex problem was fixed.

<comment><USER2> "Krokodil" (which just by the way, barely creates trace amounts of Desomorphine; the chemistry just isn't correct. No-one really knows WHAT it creates) is guaranteed to kill you. Suboxone (while possible) generally didn't have that sort of guarantee. I'm not sure which is better.

<comment><USER15> Yes

Note to readers: don't google pictures of Krokodil effects.

<comment><USER16> Unless you want to see rotten flesh and exposed bones

</comment></comment></comment></comment></comment><comment><USER17> FYI- Suboxone is actually buprenorphine combined with naloxone whereas Subutex is only buprenorphine. When Suboxone is taken sublingually as indicated, the buprenorphine is absorbed and naloxone is not. Thus, if taken as prescribed, Suboxone can be an effective detox/maintenance drug. However, if it is injected, the naloxone becomes bioavailable, binding as an antagonist to the opiod receptors and inducing withdrawal if the user was taking methadone, heroin, or buprenorphine (theoretically). Clever.

</comment><comment><USER18> Yes, there is no drug abuse in dictatorships. It can also fix crime, obesity and all kinds of problems. But it's certainly not worth it.

<comment><USER19> The US has had its dictators too. FDR was given almost absolute executive and legislative power. He openly admired european facists, describing himself, in the presence of journalists, as a blood brother of Stalin and Mussolini. He imprisoned citizens without trial.

I think a similar argument could be made about Lincoln. He too siezed unprecedented executive powers.

I'm not saying they were good or bad. I'm just trying to point out that we have had presidents that have taken extreme measures to deal with percieved crises. And we have, for the most part, interpreted this as a-ok.

<comment><USER20> _"FDR was given almost absolute executive and legislative power."_

Um, no. This is incorrect. Roosevelt's plans and projects were repeatedly frustrated by opposition in the other branches of government. That doesn't happen in dictatorships.

Much of the New Deal, for example, ended up being struck down by the Supreme Court. Roosevelt tried to prevent that from happening again by "packing" the Court with friendly justices ([http://en.wikipedia.org/wiki/Judiciary_Reorganization_Bill_o...](http://en.wikipedia.org/wiki/Judiciary_Reorganization_Bill_of_1937)), but Congress shot that plan down. He desired for years before Pearl Harbor to get the US to join with the Allied powers in opposing German and Japanese expansionism, but the Neutrality Acts (<http://en.wikipedia.org/wiki/Neutrality_Acts_of_1930s>) made it nearly impossible for him to provide any US support for the Allies at all. Even in 1941, after the fall of France and the Battle of Britain, Congress only agreed to extend the military draft instituted in 1940 by a _single vote._

You can argue whether Roosevelt was in the right on any of the policy decisions he made, but you can't argue that he was operating without checks and balances, because he wasn't.

</comment></comment></comment><comment><USER21> Interesting. This really got me thinking:

"Dependence on pot isn't a minor thing—imagine stalling the careers of a tenth of the U.S. workforce for a year—and we should certainly consider it in the negative side of the ledger when contemplating reform in drug policy."

<comment><USER22> Because the purpose of life is to work, produce as much as possible?

Talk about an addiction, an unhealthy dependence, obsession with a metric that has nothing to do with either happyness or fullfilment.

Almost as if we're actually craving enslavement. As if chasing promotions, or wealth as if we're gaining XP or coins in a videogame, is a better way to spend our time, health and energy on.

Im not saying there is no pot abuse, or working is evil, or other hippy logic, i just wanted to point out that this particular argument is flawed.

<comment><USER23> I'm with you on the whole enslavement and false idea that the purpose of life is to work, my personal pet peeve is how "passion" is used as a word that means "slavish devotion to enriching a company"

However, we live in an imperfect world and the career disruptions that can ensue from a devotion to TCH reduce people's quality of life in no uncertain terms.

<comment><USER24> I'm skeptical of your broad, unsubstantiated claims about a drug that you can't even spell correctly.

</comment></comment></comment></comment><comment><USER25> For those interested in Krokodil, there's an excellent, harrowing and _very_ NSFW documentary on it by Alison Severs: <http://www.youtube.com/watch?v=JsUH8llvTZo>

<comment><USER26> An interesting video, but fair warning before you watch: it gets pretty graphic about halfway through. They show some clips of people with the side- effects of krokodil: the skin drying out, falling off, and parts of bodies getting pretty raw.

I don't have a particularly weak stomach, but my dinner started getting restless.

<comment><USER27> Yup, even after seeing to many weird videos, this is one of the 5 worst I know.

</comment></comment></comment><comment><USER28> I wonder what the actual affect on people is of Subutex. If the effects generally are similar to pot, why bother regulating it? 30,000 people per year in the US die of alcohol related accidents and other issues, and 250,000 or so die of smoking related cancers. Yet they remain completely acceptable legal "drugs". I don't know off hand the number of deaths from illegal and misdirected drugs including violence but I am sure it's not a small number either. The inconsistency of treating each mind-altering substance is what makes little sense to me.

<comment><USER28> I found this: "The most common reported side effect of Subutex and Suboxone include: cold or flu-like symptoms, headaches, sweating, sleeping difficulties, nausea, mood swings. Like other opioids Subutex and Suboxone have been associated with respiratory depression (difficulty breathing) especially when combined with other depressants."

Sounds like a hangover.

<comment><USER2> The effects are a feeling of pure (blissful) apathy, and warmness. Suboxone is very light on the side-effect front, compared to other opiates.

</comment></comment></comment><comment><USER29> The article didn't really explain the justification for the crackdown on Subutex except for the usual "drugs are bad, mmmkay". It seems like Subutex is a good cure for misery without serious side effects.

<comment><USER30> There are plenty of undesirable side-effects:

 _can induce mild withdrawal symptoms in patients dependent on opioids; also diarrhoea, abdominal pain, anorexia, dyspepsia; vasodilatation; dyspnoea; paraesthesia, asthenia, fati- gue, agitation, anxiety; less commonly flatulence, taste disturbance, angina, hypertension, syncope, hypoxia, wheezing, cough, restlessness, depersonali- sation, dysarthria, impaired memory, hypoaesthesia, tremor, influenza-like symptoms, pyrexia, rhinitis, rigors, muscle cramp, myalgia, tinnitus, dry eye, and dry skin; rarely paralytic ileus, dysphagia, impaired concentration, and psychosis; very rarely retching, hyperventilation, hiccups, and muscle fasciculation_

        --British National Formulary 59

As well as all the complications that come from self-injecting with potentially non-sterile equipment, and of things not intended for IV use (crushed pills have a number of inactive different binders and fillers that don't dissolve and get lodged somewhere in the body, typically the lungs[2]) It's metabolism can be pretty hard on the liver as well, which is a major concern if users have hepatitis from needle sharing/reuse.

Another big problem is that since it operates as an opioid receptor anagonist (rather than an agonist, as practically all other opioids), the usual treatment for overdose -- Naloxone -- won't work very well. Buprenorphine also has a fairly hard effectiveness ceiling at ~32mg/day (although it would be a lucky/rich addict indeed who could afford that at €300/8mg quoted in the article)

Finally, if an addict ends up in hospital or requires strong pain-relief, there's not a lot of options because the blockade effect will prevent (afaik) virtually all other opioids from working.

[2] <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1276621/>

</comment></comment><comment><USER31> Is it just me, or is this article praising Subutex ? If you want to know what subutex does to people, watch this Finnish Documentary about Subutex, Reindeerspotting, Escape From Santaland: <http://www.youtube.com/watch?v=Q8O_Ot-wCIg>.

Subutex misuse is a big problem in Finland, and it seems to create more problems than solve them, at least to the information I've read about it.

</comment><comment><USER32> In summation, tough policy cleans up the majority of the drug addicts, but the diehards resort to a worse substitute that is , for lack of a better word, grotesque. I wonder if they reintroduced subutex if the old drug addicts would come back, or if just the die hards would return and be free of krokodil?

</comment><comment><USER33> I wish more people were familiar with Ibogaine. It's expensive, but it's helped two friends completely return to life with no withdrawal symptoms or desire to use again.

It has properties that break opiate withdrawal almost instantaneously, as well as other psychological effects that tend to reset senses such as smell, touch, etc, back to an almost childlike state. Very mysterious and beautiful substance.

<http://en.wikipedia.org/wiki/Ibogaine>

This is also a must-watch documentary:

Ibogaine, Rite of Passage: <http://www.youtube.com/watch?v=dPDIH9WODnk>

</comment><comment><USER34> Cycle of addiction <http://visual.ly/cycle-addiction></comment>


An optimization to help code compilation times on big CPUs - <AUTHOR> https://www.phoronix.com/scan.php?page=news_item&px=Linux-Pipe-Parallel-Job-Opt <comment><USER2> the git commit: pipe: use exclusive waits when reading or writing[1]

[1] [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ddad21d3e99c743a3aa473121dc5561679e26bb)

<comment><USER3> I am always amazed at the quality of linux kernel commit messages.

<comment><USER4> Indeed. Those two lines in the test-case are particularly excellent:

      /* 64 processes */
      fork(); fork(); fork(); fork(); fork(); fork();

I can totally see most people, myself included, writing a dozen of lines instead, with a for loop, checking for parent/child/error return code, etc. Which might be preferable for some code somewhere deep inside the app logic that will potentially run on a resource-constrained machine. But for the explanation code to be read by a human, this one-liner is such a good choice!

</comment></comment></comment><comment><USER5> Now just make "-j" the default and all is good :) Why _shouldn 't_ make use the available resources by default?

<comment><USER6> I really hate it when people do that and don't provide a way to disable it.

There are a number of python libraries I can't install on my laptop easily because the native code runs out of physical (4GB!) memory spawning compiler jobs and everything starts thrashing, it's just dumb to go forking without asking the user first. People who really want it can give make the -j flag.

<comment><USER7> Bazel is the worst at this. When you try to eg; build tensorflow from source it maxes out all the cores, uses up as much memory as it can, and then crashes when the OOM killer eventually kills it. This is even on a 64GB 64 core machine.

Manually specifying resources doesn't work well either because it uses 2x+ the resources you allocate it.

</comment></comment></comment><comment><USER8> Does this affect select() or only read()? Today if N procs select() on a single pipe, all will be woken up if the pipe becomes readable. Will this now mean that only one will be awoken?

</comment><comment><USER9> Could the fix have any potential negative effects on other workloads?

<comment><USER10> Some other build systems use the pipe token approach too, rust's cargo for example.

</comment></comment><comment><USER11> GNU Make has been fixed, but I wonder if there are other programs which would also have similar bugs in their code? I am reminded of when systemd exposed bugs in system startup scripts, and everybody instead started hating systemd for breaking their systems.

<comment><USER12> It's not GNU make that got fixed. It's the pipe system call that Linus optimized. Make uses pipe as a synchronization mechanism. So all programs that use pipe this will benefit.

<comment><USER13> What the parent comment is referring to is a pipe handling bug in early versions of GNU make that prevented kernel optimizations from happening earlier on.

</comment></comment></comment><comment><USER14> Suddenly LibreOffice build time's increase substantially.

<comment><USER15> What do you mean?

<comment><USER14> LibreOffice relies extensively on parallel build from Gnu make.

Edit: crap, that autocorrected on my iPhone - that should have been decrease!

</comment></comment></comment><comment><USER16> Good example of how we develop software these days: instead of fixing GNU make by ripping out that antiquated pipe-based jobserver and replacing it with proper multi-threaded parallelism[1], we rather optimize the operating system to make the antiquated stuff work better.

[1] Having hacked on GNU make I know this won't be easy (it's quite a mess). In fact, it would probably be easier to replace it entirely and fix some of its other deficiencies in the process.

<comment><USER17> I would not call avoiding a classic thundering herd problem a bad choice, especially when the top maintainer of Linux does it himself in Linux: which is arguably more probable than him rewriting GNU Make (well we all know he _could_ do it, but this would still be less probable...)

Plus it will not only optimize GNU Make workloads, but potentially other programs that do that. And to be honest, playing with pipe for signaling (and more rarely token counting) is STILL a must-have way to do IPC portably, esp. if you want to integrate with polling on fds. Various OSes have also various new things, but they are non-portable -- maybe someone should try to get eventfd&friends in POSIX?

Anyway, if that's a "good example of how we develop software these days", I would say we managed to develop software the right way at last, making basic stuff work well before succumbing to the tentation to rewrite everything all the time just to play with new shinny techs, getting fresh bugs in the process.

Also you know what has evolved in the last few years, motivating this perf fix? Availability of HIGHLY parallel computers for not too expensive. Yes, I continue to find it highly refreshing that work is done to get all the boring historical software work better in that context. Maybe you think we can afford rewriting all the things all the time to follow supposedly radical technological changes (and using less well designed OSes?), but if so then this thought is not shared widely or at least not followed with action. Rightly so because economically the outcome would be doubtful: just look at the patch, it is way smaller than an hypothetical shiny new rewrite of GNU Make...</comment></comment>


Haskell Curses and Conundrums - <AUTHOR> https://github.com/justosophy/curses-and-conundrums <comment><AUTHOR> Some simplified exercises of isomorphic equivalence in data structures.

Haskell experts may now commence their superior mocking ;)</comment>


Developer Toolbar for React Projects - <AUTHOR> https://github.com/deecewan/dev-bar <comment><AUTHOR> Let me know what you think. After whatever feedback you've got.

<comment><USER2> Looks like an interesting piece of work to me.

If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment></comment>


Amazon Beats Apple And Google To Cloud-Based Music Storage/Streaming - <AUTHOR> http://techcrunch.com/2011/03/28/amazon-cloud-drive-player/ <comment><USER2> Well, it remains to be seen if it is successful, as being the first to market doesn't translate in being the most successful one or that the market is worth pursuing.

That said, I love it how Amazon gets shit done.

I wouldn't be surprised to see them launch a credible Facebook alternative either, were integration with Amazon reviews would be their killer feature.

</comment><comment><USER3> Isn't that kind of like winning a race to give money to a panhandler? Especially if the two people you think you're racing aren't even trying? We've had dozens (I assume - I've only tried 2 or 3 myself) of startups in this space.

</comment><comment><USER4> Didn't Apple technically win by acquiring (then subsequently closing down) lala ?

<comment><USER5> Closing down? I'd say significantly rebranding. We'll see, most likely, the week of June 6th.

</comment></comment><comment><USER6> fortunately my wallet's content will not be impacted by this news. Being in Italy helps you spend less money, Yay! :(

<comment><USER7> Ditto for Brazil... In my case, most apps are not for sale in AppStore, for example (not even Angry Birds).

</comment></comment><comment><USER8> Apple beats Amazon to a useful media distribution store by a decade.

<comment><USER9> You're missing the whole point.

<comment><USER8> Maybe. But so are all the headlines about Amazon. Yes, Amazon beat Apple and Google to the punch on the media locker, but the extent to which that is relevant is questionable. Apple sells 70% of the digital music in America compared to Amazon's 12%.

[http://arstechnica.com/media/news/2010/05/amazon-elbows- its-...](http://arstechnica.com/media/news/2010/05/amazon-elbows-its-way-back- into-number-two-music-sales-slot.ars)

It's good to see Amazon getting in there and releasing forward-looking products, but it is also important to realize that they still have a ton of catching up to do. If Blockbuster released an online video locker product I don't think it would dramatically affect Netflix.

Point simply: Kudos to Amazon for getting their first. Not sure it's going to make much of a difference seeing as Apple's media locker is coming out in the next few months (as is Google's apparently). Customers are sticky to their music stores.</comment></comment></comment>