Can they see my dick pic? - <AUTHOR> http://cantheyseemydick.com/ <comment><USER2> First of all, I want to say, this is one of the most brilliant things I've seen in a while and I think is exactly the line of reasoning you need to pursue to make effective action in the world: Find a _highly visible_ line in the sand that everyone can agree is bad, and draw a clear metaphor to a current problem to show why that problem is bad. Bravo to the creators.

I came here to comment that it's interesting this story has gotten flagged off the front page immediately. A more immature mind would have jumped to "OMG! The NSA trolls are burying this story!", but in this case, it's pretty clear that some people flagged purely because of the title.

It creates an interesting problem for the HN community, because (as a long- time hacker news reader) I feel this is _exactly_ the type of content that would be interesting to most _hackers_ , but probably least interesting to non-hackers who come here because of YCombinator's prominence as a non-strange attractor and just simply don't want to hear genitalia words in their news.

I'm sure this comment will fall on deaf ears, but there was a Hacker News once that would have brook'd the eternal VC industry to keep his state in Hackerdom, as easily as a (hacker-king? I'm stretching here)

<comment><AUTHOR> Agreed. John Oliver's approach to making government mass surveillance tangible for the masses is an awesome example of a social hack too.

Edit:words

</comment></comment><comment><USER3> I think that adding a call to action would be useful:

Now the government has the right to see your dick. If you want this to change, call your representative and tell him/her to vote againts the Patrioct Act reauthorization on June the 1st.

<comment><USER4> > call your representative and tell him

Or her. ;)

<comment><USER3> Yes, you are right: thanks for the friendly heads up! :)

</comment></comment></comment><comment><USER5> Screenshot of the website for those who don't want to click it at work: [http://i.imgur.com/5EQuKlO.png](http://i.imgur.com/5EQuKlO.png)

<comment><USER6> Not that it would make it any less NSFW though with those big ass letters though, would it? :D

<comment><USER7> I think the main idea would be to prevent the term "dick" appearing in traffic logs.

<comment><USER8> I thought that term would be a rather harmless abbreviation of a first name - in the very same country that is prudishly labeling lots of stuff NSFW?

Seriously, 'dick' in a traffic log is bad? And 'dick' already comes up in this very story's title..

</comment></comment></comment></comment><comment><USER4> I think this is fantastic. I would recommend attributing Edward Snowden for the quotes being used though.

<comment><USER9> Good idea, saved it for later in the rush to transcribe.

</comment></comment><comment><USER10> (Tedious disclaimer: my opinion, not my employer's. Not representing anybody but myself. I work at Google, not on gmail.)

While the main point of this article is about legislation that enables interception, they're using gmail as an example and there's something I'd like to point out (took a little digging to find a place where this had been said publicly):

[http://googleblog.blogspot.co.uk/2014/03/staying-at- forefron...](http://googleblog.blogspot.co.uk/2014/03/staying-at-forefront-of- email-security.html)

"In addition, every single email message you send or receive—100 percent of them—is encrypted while moving internally. This ensures that your messages are safe not only when they move between you and Gmail's servers, but also as they move between Google's data centers—something we made a top priority after last summer's revelations."

The NSA can lawfully intercept all of Google's inter-datacenter traffic at the borders of the US. Good luck to them in doing anything useful with this firehose of encrypted traffic.

<comment><USER11> And you're so sure that there isn't a single NSA agent working at Google who could subvert your systems? Let's be realistic

<comment><USER10> It would be a fairly poorly designed system if any individual could subvert it without getting caught. It's not all that important who's paying them ;)

I can't talk about internal systems at all, of course.

</comment></comment></comment><comment><USER12> I'm curious about what this is, but I dare not click the link at work.

<comment><AUTHOR> It's SFW. Just text, even the youtube video from John Oliver is SFW IIRC.

<comment><USER13> The video is SFW as long as you're not playing it through speakers.

</comment></comment></comment><comment><USER14> The entire premise of this is wrong. Research has shown that the majority of Americans favor allowing the government to take naked pictures of them, even if it doesn't result in extra safety. Jeffrey Rosen wrote an entire book about this called The Naked Crowd:

[http://www.amazon.com/Naked-Crowd-Reclaiming-Security- Freedo...](http://www.amazon.com/Naked-Crowd-Reclaiming-Security- Freedom/dp/0375759859/ref=sr_1_1?ie=UTF8&qid=1428335270&sr=8-1&keywords=the+naked+crowd)

<comment><USER15> John Oliver made it pretty clear in his street interviews that people were unanimously uncomfortable with the US government collecting and storing dick pics.

While I have not read the book you linked, I think the dick pic premise captures the extent of the NSA's programs quite well and frames the issue in a down-to-earth way. It lets people see the domestic side of the issue, which is the difference between "Edward Snowden is a traitor who has compromised our national security" to "holy shit, the NSA is invading my privacy wtf..."

</comment></comment><comment><USER3> Ok, it was open sourced: [https://github.com/olivierlacan/can-they-see-my- dick](https://github.com/olivierlacan/can-they-see-my-dick)

</comment><comment><USER3> I think that adding another explanatory paragraph could be useful, in order to make it clear that is not just dick pics that we are talking about.

Think about your most intimate pictures, your most intimate conversations. Would you want to share them with hundred of thousands of people? Because that's happening already. Good news, you can change this.

<comment><USER9> Good idea, pull requests accepted: [https://github.com/olivierlacan/can-they- see-my-dick/pulls](https://github.com/olivierlacan/can-they-see-my-dick/pulls)

No being a jerk, seriously I'd love help with the copy. :-)

<comment><USER3> You can steal what I wrote for now, if you don't I will try to do a PR in the next days. :-) (et bravo pour le lien à LQN <3)

</comment></comment></comment><comment><USER16> This will backfire. Freedom of expression is about a lot more than freedom to send around pictures of naughty bits. The public should not get the impression that freedom from surveillance is being demanded by puerile hornballs, lest they think that those who have their privacy compromised by the government _deserve_ it.

Please, please, take this down.

<comment><AUTHOR> Have you watched the John Oliver clip on Youtube yet? I think the motivation for going this route is clearly outlined, and firmly based in humor.

</comment></comment><comment><USER17> You might want to add some more meta tags for images, twitter cards, etc. For those who are sharing this across social media. For instance, when I shared to FB it didn't pick up any of the metadata to show a snippet.

<comment><USER9> Do you mind helping out? [https://github.com/olivierlacan/can-they-see-my- dick/issues](https://github.com/olivierlacan/can-they-see-my-dick/issues)

</comment></comment><comment><USER18> Dick pics are seen as a source of humor in our culture. "Can they see my pu __* " would be more effective.

</comment><comment><USER19> I get the intent...

...but I'm not sure anyone, anywhere wants to see dick pics, anyway. This will backfire spectacularly.

Thanks, "bro"

<comment><USER3> They might not want to, but they already do, and not just through the quoted programs: look up Opticnerve, eventually on [https://www.nsa- observer.net/](https://www.nsa-observer.net/)

<comment><USER19> You misunderstand.

What I mean is "Oh noes the NSA may be chilling effect on unwanted dick pics that stuff my inbox" could be a strong pro-NSA selling point to a very large portion of the public.

Very, very few people are interested in receiving dick pics. Far, far fewer than there are people interested in sending them. Failure to understand this is a complete failure of understanding dick pics.

<comment><USER3> I think you are over-reducing the statement. What we talk about is John Oliver's dick pick, Scarlett Johannson's nude selfie, and you passing naked in front of your computer/phone. The last one might remain unknown to the vast majority of the public, but I think the first two are being understood.</comment></comment></comment></comment>


Enhancing Data Visualization with SVG Filters - <AUTHOR> http://vasir.net/blog/data-visualization/enhancing-data-visualization-with-svg-filters

<comment><USER2> the author suggests using the blur filter (if you don't know SVG, it's exactly what you think it is) in quantitative plots to show uncertainty (error). This is great idea, as evidenced by the couple of examples he gives.</comment>


Apple releases the tablet. - <AUTHOR> http://blog.styleguidance.com/post/355658636/apple-releases-the-tablet <comment><USER2> Incorrect headline. Apple hasn't announced anything in the present tense.

<comment><AUTHOR> There is too much hype, it's not organic. Frankly if Apple doesn't display a tablet tomorrow, their stock price will go into a free fall.

<comment><USER3> And won't you be looking silly tomorrow when Apple releases a full suite of wearable devices for digital media creators, including augmented reality spectacles and brushes that act as 3D motion capture devices and can read colors off of real world objects.

#not breaking any nda</comment></comment></comment>


How LSD Almost Became the 13th Step (2019) - <AUTHOR> https://prohbtd.com/read/alcoholics-anonymous-how-lsd-almost-became-the-13th-step/ <comment><USER2> Anecdotally during a period of 3 or 4 months when I had gone to numerous Ayahuasca ceremonies here in Canada, I saw the progression of a self- proclaimed alcoholic who felt like she was going to die soon from the illness - and physically she was very pale and unwell looking; so much so that she was seeking and willing to try anything including Ayahuasca, which is an entheogen similar to but different than LSD - and arguably being done in a ceremony setting provides a different container as well.

There's an opportunity after a ceremony to share during a talking circle. I can't remember if the woman shared during then or to me afterward, however she told me in the morning that she could feel like alcohol no longer had a hold over her. I saw her 3 or 4 more times over a 3 to 4 month period at ceremonies - and by the end she looked very healthy, her skin had a healthy pink tone to it - and she was beaming with energy compared to before.

Another experience to share related to alcohol and Ayahuasca: an ex-girlfriend of mine had gone to a few ceremonies with me. After her first ceremony she shared two notable things. The first was an insight from her family dynamics that she could see from a holistic level looking down at the structure, which seemed to give her great comfort, reducing her baseline stress. The second was she was presented or saw simultaneously two separate "objects": she saw alcohol and she saw social situations. She's Russian so perhaps the deep cultural aspect of alcohol that seems to go with her background, along with her family always immediately offering a drink to her as their greeting when she'd visit are examples of how deeply engrained alcohol and socializing were for her. After her experiencing that division separating alcohol consumption and social situations, she roughly said she no longer felt the need to drink when socializing - though she never had a problem with alcohol - she felt like whatever association and connection to alcohol simply diminished, arguably due to the clear division of the contexts; unlinking the healthy engagement of socializing from alcohol consumption.

<comment><USER3> Entheogens increase your consciousness. High consciousness gets us closer to the truth of what reality is, which allows us to break our self-deceptions.

<comment><USER2> Indeed, they temporarily eliminate the ego and its bias from the equation of the mind, allowing the rest of the mind an unfiltered view and clear understanding based on whatever intellectual capabilities one inherently has; ego death, ego dissolution.

<comment><USER4> I have also experienced the elimination of my ego with MDMA use. I suspect this is the explanation that MDMA works as a treatment for PTSD.

<comment><USER5> In my opinion, the reason it works well for PTSD, is because it temporarily suppresses feelings of fear, shame and embarrassment. It also makes you more trusting of other people, which can be good in a therapeutic setting, as it might make it easier to open up. On MDMA, you can look at your own past without any judgment. That makes it easier to look at things in a way that's more detached, and begin to process what actually happened without being flooded by negative thoughts.

</comment></comment></comment></comment></comment><comment><USER6> My annoyance is that we aren't taught about alcoholism or that alcohol (and caffeine) are drugs.

Once your brain chemistry is changed, it takes significant pain to get it back. And according to the book Power of Habit, it never goes away.

Then alcoholics have the need to make everyone else drink. It's a cycle.

I'm glad I was addicted to alcohol and weed, easier to break. But I still relapse.

</comment><comment><USER7> A cure for alcoholism that works fifty percent of the time is ground breaking. How could doctors not be impressed? The success rate for AA itself is about 2%. What has a better rate of success than 50%?

<comment><USER8> As a country, we are just BARELY getting to the point where people are willing to be public in their support of marijuana legalization. We have a long way to go before entheogens are legalized federally. But I think if there is any way to achieve that, it would be through doctors attesting to their efficacy in treating various illnesses. It's the same thing we went through with marijuana -- show the people there ARE medical uses, that the world is not ending because of it, and then they accept a wider use.

<comment><USER5> I think it would make sense to start by legalizing mushrooms. The fact that they are very prevalent in nature will make it easier for people to accept them. They're also very safe, probably less addictive than marijuana (do you know anyone who takes mushrooms daily?), and there are already a number of studies showing therapeutic benefits.

</comment></comment></comment><comment><USER9> LSD helped me give up nicotine and consuming animal flesh. It was very clear to me that I didn't need either in my life. Why harm myself or other beings for such mundane pleasure when I could now access the transcendent (now through meditation).

</comment><comment><USER10> Misleading article title.

> Wilson later distanced himself from AA, as many other influential members of > the program took issue with the idea of incorporating a psychoactive drug > into a system of steps designed to end drug use.

> But, according to Pass It On, published in 1984 by AA World Services in New > York, the movement was totally against his suggestions. "As word of Bill's > activities reached the fellowship there were inevitable repercussions. Most > AAs were violently opposed to his experimenting with a mind-altering > substance. LSD was then totally unfamiliar, poorly researched, and entirely > experimental – and Bill was taking it."

[https://www.theguardian.com/science/2012/aug/23/lsd-help- alc...](https://www.theguardian.com/science/2012/aug/23/lsd-help-alcoholics- theory)

</comment><comment><USER11> What's funny is that the AA I'm in doesn't oppose any treatment where you are under a doctor's care. I honestly don't know where that line is drawn in clinical or medical trials or experiments. I will say that personally, if this can help eliminate or prevent addiction, I'm all for it.</comment>


Ask HN: Should I leave tech for international trade? - <AUTHOR> Hey there. This a throwaway account.
I'm a Software Engineer w/ 10+ years of experience. Live in NY, have a family and a decent salary - $150k. I'm expecting my Green Card in a month or so. I have always wanted to start a business in the tech industry. Like many of you, I think through various ideas every single day, build prototypes, read HN and al that.
But, a week ago my brother proposed me to start a US business in the International Import/Export industry. He works at Customs and Border Protection in my home country and is familiar with cargo, container ships and stuff like that.
The US company he wants me to start would be a wholesale supplier of steel, wood and/or food and beverages. My brother would be a partner who would export all the products from our home country.
The problem is that this whole niche is very grey to me. It's the same as I would ask my gramma to go work at SpaceX. Well, maybe not that bad, since I can read from the Internets and my gramma doesn't really know what Google is. But anyways, you get the point.
I love HN community and would GREATLY appreciate any feedback on this. Basically, I don't know what to do. <comment><USER2> Only you can answer. But to me sounds like a prettyy bad idea.

Doing business with any family member is generally not a good idea.

Not to mention leaving a high-paying industry to go into some random thing you don't know anything about.

</comment><comment><USER3> Guessing your brother is in India or something similar. Business is different there, lots of small traders do import and export of basic commodities. Not really going to be viable in the US unless you have some advantage.

<comment><AUTHOR> No, we are actually from Russia. Moscow.

</comment></comment><comment><USER4> I wouldn't leave tech. At the most, I would give it a try in my free time first.

I think on potential problem is that your brother may be able to do some things that are in a legal gray area. This happens a lot in many countries, but you don't want your name on the company if something goes sideways.

To be blunt, if your home country is China, India, or any developing country where favors at the border are a thing, there is absolutely no way I would do this as stated.

<comment><AUTHOR> We are originally from Moscow, Russia.

</comment></comment><comment><USER5> As they say, don't give up your day job yet.

Test the waters and investigate the new business opportunity without quitting your job. Check your employment agreement, maybe you can even start a business outside of work. More likely if the business is in a different industry, like this sounds.

Also, it sounds like you are looking for an excuse to leave your day job. Maybe investigate that a bit by doing some deep thinking.

</comment><comment><USER6> Don't quit your job but try out the opportunity on the side. Try to find one person/business in US who is willing to buy what you are selling. Until you have made that sale, you don't have a business just "Hopes & Dreams."

Sell first, build later. Nothing happens until someone somewhere buys something. These should be your guiding principles.</comment>


Hand.js: a polyfill for supporting pointer events on every browser - <AUTHOR> http://handjs.codeplex.com/

<comment><AUTHOR> It was introduced during the Microsoft Techdays'13 in Paris two weeks ago. Its nice to see Microsoft playing nicely with the standards body and the other browsers.

Their proposed API looks like a step forward from the iOS touchevent proposal.</comment>


Ask HN: What is up with these awful albums in Rdio's heavy rotation section?  - <AUTHOR>

The current number two top album on Rdio is "Jazz for Dogs" by Little Robertson. It's also on iTunes (see here: https://itunes.apple.com/us/album/sniff/id668974536?i=668974736) and other music services. I assume it's on Spotify as well.
The album itself consists of 50 songs each exactly 30 seconds long. The songs consists of what sounds like midi being played without any sound fonts installed overlaid with random sound effects of dogs barking.
Song titles include: 'Woof Woof!', 'I Love Bones' and 'Slap that Liver Treat'.
Jazz for Dogs is the most recent addition in this style. Other albums include 'Where's My Chenny' (seems to be based on the movie Commando), 'Three Magi' and rather amusingly 'A Kim Jong Christmas' (featuring the song, 'Deck the Halls with Capitalists').
I understand theirs a lot of terrible music being self released now, but you've got to understand that all four of these albums are rating higher then say Daft Punks 'Random Access Memories' or Kanye Wests new 'Yesus' album.
I'm guessing that it's some sort of spam (they get paid per play?) does anyone on Hacker News work at Rdio and can explain what's going on? Or if not, I'd love to hear some theories on why these albums are ranked the way they are. <comment><USER2> Could it have something to do with the new "You.FM" feature they're doing with personalized stations?</comment>


Show HN: Why you should not use feature branches - <AUTHOR> https://fire.ci/blog/why-you-should-not-use-feature-branches/ <comment><USER2> A "feature branch" means something much different to my teams. A feature branch for us is a short-life topic branch, and typically for one use case, kanban card, etc.

We use short-life topic branches for each feature, each bug fix, each infrastructure-as-code change, each documentation update, etc.

We prefer short-life topic branches vs. committing to the `master` branch (or equivalent `develop` branch) because of multiple reasons:

1\. A topic branch gives good code isolation for distributed development: I can share a topic branch with you, directly, without needing to merge to master.

2\. A topic branch makes it really easy to do many kinds of popular git workflows; this includes many popular CI servers, git automation scripts, git aliases, etc.

3\. A topic branch is great for integrating early and often into code reviews, and also with master. For example, we use a feature branch that uses feature toggles, and we can do CI/CD to propose changes to master as often as we want, and we can rebase the topic branch as often as we want. We can choose whether a repo will prefer merge, or rebase, or rebase with preserve, and between elided linear history or real graph history.

4\. We favor automatic integration, meaning when we push a topic branch, and the reviews are all good, and the tests are all green, then the CI/CD does an automatic integration process, including an automatic deploy. When the topic is integrated, then the topic branch is deletable.

5\. Finally, I've tried the "TBD just merge to master" approach with multiple teams, and inevitably it turns out to be significantly harder and more complex to coordinate, especially at speed, scale, and with more stakeholders.

If you're interested in git, you can see some of the git alias topic branch commands that we use:

[https://github.com/GitAlias/gitalias/blob/master/gitalias.tx...](https://github.com/GitAlias/gitalias/blob/master/gitalias.txt)

<comment><USER3> How do you name your topic branches? We previously used a bug tracking system in parallel with this same process, so we used ticket numbers as the prefix for branch names. On our current project, we are using Trello as the driving tool which obviously doesn't have the simple numbers so we end up with odd inscrutable branch names and I haven't yet found a good way to normalize them.

<comment><USER2> Each team is free to choose their own way. Personally I like topic branch names that are read like a present tense imperative commit messages e.g. add_feature_for_user_to_like_a_post, fix_relation_between_a user_and_a_post, optimize_search_speed_for_a_user_to_see_posts. The names are long and meaningful. Autocompletion makes these work well.

Our git commit message conventions are:

[https://github.com/joelparkerhenderson/git_commit_message](https://github.com/joelparkerhenderson/git_commit_message)

To store info about metadata, such as task board number, we edit the branch description, and enable the description to go into the merge message.

A good short intro to branch descriptions:

[https://ericjmritz.wordpress.com/2015/11/13/using-branch- des...](https://ericjmritz.wordpress.com/2015/11/13/using-branch-descriptions- in-git/)

</comment></comment></comment><comment><USER4> We are using features branch that we are rebasing on master.

This allow to have code reviews before something is actually in master (something you might or might not want depending on your worflow or criticity of the sw you are working on)

Rebasing (and squashing) allow to keep a linear and clean history.

Rebasing and squashing also have downsides, you lose the finer day to day commits, in exchange of ideal history, but at least it should be mentioned in a 2019 post about having too much feature branches in git...

</comment><comment><USER5> Someone forgot about continuously merging master to feature branch to keep the merge simple.

<comment><USER6> If everyone is working in a feature branch and only bug fixes are done in master, then most of the merges will be simple. However, when a feature is done and merged to master, all the feature branches need to merge the work and that merge will be disproportionately difficult.

kennethh posted a link that explains this well: [https://martinfowler.com/bliki/FeatureBranch.html](https://martinfowler.com/bliki/FeatureBranch.html)

<comment><USER7> Only if you don't know rerere, and don't use it immediately after updating master. I carry tons of feature branches with me, which are automatically rebased. Only once or twice a year I need to fixup things a bit, and those things are the things I immediately worked on, so I know for sure how to merge it. Everything is scripted.

If you let them stall it becomes a mess, sure. If do it properly it's trivial.

</comment></comment></comment><comment><USER8> Your git strategy should depends on your business release cycle and priorities. In this case, it's a trade-off between dev branch stability and development speed.

With trunk-based development, everyone sees everyone else's work in progress and it's easier to integrate different features together. With feature branches, however, dev is more stable and there's more responsibility on merging to branch back to dev.

Are you deploying to public a few times a day like a web service, or are you working towards an early release, like a AAA game? Does your team sit together in one room, collaborating with one another, other do they take completely independent task and do them remotely, working from all across the globe, with the only point of interaction being a pull request once or twice a week?

It's impossible to say what's better or what's worse without these priors.

</comment><comment><USER9>
      - "Show HN" when there is nothing really to show
      - Submitted by the author of the post
      - Author of the post is founder of company
      - Provocative, click-baity Headline

We are better than that, HN.

<comment><USER10> Submitting your own stuff is OK here. You can add some comment explaining that you are willing to answer questions, but it is optional. Anyway, most people here will assume that the owner will read the comments sooner or later. (Reposting and reposting and reposting your stuff is not OK.)

Anyway, this is an article that is on-topic, but it is not a good ShowHN. From [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

> _Blog posts, sign-up pages, and fundraisers can 't be tried out, so they > can't be Show HNs._

(Disclaimer: I prefer rebasing.)

<comment><AUTHOR> Ok thanks. Won't post articles as Show HN in the future.

</comment></comment></comment><comment><USER11> It's more that feature branches should be __rebased __instead of merging the main branch into it (like most developers unfortunately do)

        [pull]
            rebase = true

in your ~/.gitconfig, and just pull the branch your forked from

This way, the git history is linear, clean and readable

<comment><USER12> Rebase is so terrible and not because of the lost commit history (most of which deserves to be lost, imho. git merge history is too verbose and oftentimes not useful).

My issue with rebase is that as soon as you want a single other person to commit code to that branch, you can no longer rebase. Everything must be merged from that point on, otherwise the histories diverge and you wind up in rebase/merge hell.

The only alternative I've found is to over-communicate every push to your co- worker because it requires him to stash his changes, delete his local branch, pull down the "new" remote branch and re-apply his changes.

<comment><USER13> use interactive rebase?

</comment></comment></comment><comment><USER14> Not really a show HN.

Also, rebase master into your feature branches regularly.

<comment><USER15> I recommend pulling instead. That way you do not lose information on when given code was done and conflict resolution is visible, making hacks like git- rerere less required and automated merging tools more potent.

This is really important when there are parallel feature branches and even more so when features are codependent.

E.g. if feature a depends on feature b, if you rebase feature a you cannot just pull it into feature b as there will be duplicate commits.

If you want nice lines you should hire a painter. If you want easy merges, merge instead of rebasing.

</comment></comment><comment><USER16> One of the issues with feature branches is that long-lived feature branches easily go stale, and each day that passes by makes it riskier to merge them into master.

While I agree with the author on the general idea of trunk-based development (and feature switches), can't we get the best of both worlds by allowing short-lived pull requests where code review can happen?

I'd be curious to hear from teams here who push directly to master and how this workflow works for them.

<comment><USER17> Not doing any of this myself, but the keyword here is "rebase".

(But yeah, there's a problem with reduced testing during feature development. What if a feature branch breaks the main branch and it does not get noted during feature development? I'd argue if it affects the core then it's not strictly a "feature")

</comment></comment><comment><USER17> I guess the main advantage of feature branches is that you can easily drop them if it turns out the feature was a bad idea or too hard to implement.

The advantage of trunk based development would be that the feature gets potentially more testing. Same goes for interactions with the main line code - if feature development breaks the core in subtle ways, it will be noticed earlier using trunk based development.

<comment><USER15> It will be noticed - by angry users. Which is why untested continuous deployment is madness.

When you do checkpoint regular releases done often, you get a chance to smoketest and block a release. Automated smoke tests only go so far in fixing this - if you could cheaply, reliably and completely fully automate testing, everyone would already do that.

About the only way to do continuous deployment is to not deploy into production but use lagged deployment practice...

<comment><USER17> Yes - in my case the "users" are just my colleagues (and yes, they could get angry, but the feedback can be worth it).

I believe that "trunk" is not commonly meant to be immediately deployed to users. But, maybe things are different in the web world, where "deploy" is as easy as "upload to server"?

</comment></comment></comment><comment><USER18> I like TBD -- a lot. However there are a couple of problems with it. If your team is not collocated in a time zone then you'll one one guy (me, for instance) who will push 8 hours of development into trunk without anyone else getting a chance to look at it.

The same thing happens if you have someone who just "disappears" for a day or two and effectively has a feature branch. You need to have discipline on your team to push often (I like to push at least every 20 minutes).

I also tend to think that continuous deployment with TBD is risky. It depends on how good your automated acceptance tests are, but I tend to like to do a manual sanity check before deployment. It's a lot easier when you are not working on a moving target.

Finally, sometimes you just _have_ to break something in order to change its direction. This forces you into a feature branch if you are doing continuous deployment.

We've occasionally experimented with having an "integration branch" that acts like trunk but isn't deployed. You can then time your trunk deployments, potentially cherry picking from the integration branch. It seems like a good solution, but I've found it to be more trouble than its worth most of the time.

Having said all that, my preference would be to abandon continuous deployment and instead have regular deployment (say once a week or once every 2 weeks) with a mechanism for hot patches. Then force everyone to work mostly core hours and have continuous integration (with commits coming in every 5 minutes or so). In my experience this has produced dramatically better results than feature branches.

However... On my team it is impossible (not least because I'm 9 time zones away from the majority of my team mates). So feature branches are an acceptable second best.

<comment><USER17> > (I like to push at least every 20 minutes)

That sounds _extreme_ to me. What kind of development do you do that makes this possible? I rarely finish something within 20 minutes. Often, I'm thinking about the right way to do something for a day or longer before I decide to push some results. (UPDATE, before I even start to write some code!)

<comment><USER19> I'd even go as far as to say that any code that was written in the span of 20 minutes can't possibly be good code, and doesn't deserve to be in master. The code quality and commit history must be pretty terrible in a project like this.

<comment><USER18> If you want to see some typical code from me, here are the commits from an experimental side project: [https://gitlab.com/mikekchar/testy/commits/master](https://gitlab.com/mikekchar/testy/commits/master)

Some caveats: I was experimenting with a different way of doing OOP in JS. Here is a description of the design: [https://gitlab.com/mikekchar/testy/blob/master/design.md](https://gitlab.com/mikekchar/testy/blob/master/design.md) There is also a coding standard that I was following: [https://gitlab.com/mikekchar/testy/blob/master/coding_standa...](https://gitlab.com/mikekchar/testy/blob/master/coding_standard.md) It's not one that I advocate, it was one that I was experimenting with.

Some of the code in there is not great. Some of it is OK. It's not a big project, but it will give you an idea of the scope I use when I make commits. I use a very conservative approach when programming -- I don't pull everything apart and then try to build it back up. Instead I refactor everything and make incremental improvements. Every commit should improve either the quality of the code or add functionality. Especially in this project, I was building a test framework, so I didn't have a test framework to work with. This meant I had to use an even more conservative approach than normal. However, like I said it should give you a good idea.

Perhaps you think this is bad code. I don't think it is. It's got a strange style (because that was the point of the exercise), but generally it was quite nice to work with. There are 2 pretty nasty hacks that I made in order to get the framework bootstrapped. I would have improved them eventually, but I ended up ending the project early. If I were to really criticise my work here, I would say that my commit messages are pretty awful. Interestingly, the TODO items that I check off in the actual commit are quite good IMHO. Probably I should cut and paste them, but... it's a personal project in my spare time... I was being lazy :-P

I guess I'm responding to your comment mainly to hopefully open your mind to different ways of doing things. Maybe you'll be able to see it, maybe you won't. One of the things I've found in this job is that there are a lot of people who are stuck in "It's either my way or it's crap". Your comment seems to indicate that you might be one of those people. But in the case you are not, I hope you'll find the code interesting.

I've worked on small projects and I've worked on big projects (I once "owned" a million lines of code!). The style I use now evolved based on my experiences. My basic approach is to look at a piece of code and try to find a general strategy for what I want to do. If I don't know the code, that can take a long time, but once I've figured out what I'm doing, things can go pretty rapidly.

I make a TODO list of what I'm planning to do. Then I look at the code for a minute or two and ask myself, "Can I get there from here?" If the answer is "No", then I ask myself, "What would I ideally want?" Then I write that down in my TODO. Usually it's a fair number of things.

Normally those facilities require pure refactoring (i.e. changing the code in a way that doesn't change behaviour). I try to break up my challenge in such a way that I make an improvement to the code, and that keeps the behaviour intact. Sometimes before I start I need to write tests to document the current behaviour.

So a typical session would be: Write test(s) that are lacking. Check in code. Refactor code to provide facility(s) that I'm going to want. Check in code. Make a behavioral change with tests. Check in code. Then go back to my TODO list to get the next step.

I _will_ leave "bad" code in the build -- sometimes for a very long time, if I don't have a good idea for how it "should" look. Even if there is a "good" way to represent it, I'll often put it off if I don't know that this "good" way is going to fit with the direction the code is going. Overworking a piece of code often leads to unintentional inflexibility and sometimes good looking code adds constraints that you don't need. However, because the code looks good, nobody will refactor it and remove the constraints, leading to overly complex code.

If you've gotten this far, you can see some of the challenges for TBD with this method, though. Every change has to keep the system completely functional! This means very deliberate and very careful modifications. It's difficult, but there is plenty of upside. IMHO there is more upside than downside by quite a margin. YMMV (and I won't tell you that you must be a crap programmer simply because you do things differently than me ;-) ).

Edit: I went through some of your commits on [https://github.com/tshatrov/ichiran](https://github.com/tshatrov/ichiran) It's interesting to me that the commit size is not really that different than mine. There are a couple of places I would have split it up into 2 or 3 chunks, but we're not talking about order of magnitude stuff here. I'm curious how long you spend on a commit. Nice project, BTW. I'm not a stranger to building that kind of tool ;-) I actually built an English parser in FORTH once. I also built: [https://github.com/mikekchar/JLDrill](https://github.com/mikekchar/JLDrill) (which actually _is_ awful code... and it doesn't actually run any more thanks to bitrot).

<comment><USER19> Well, I won't judge personal open-source projects (where there's usually only one contributor) on the same level as large collaborative projects where code quality and commit history actually matters. Ichiran is not a typical project because most of commits (especially recently) are "data" commits and not "logic" commits. I do run tests before every commit, but if there's no programming logic changes I can bump it into prod right away. Commits that actually change the logic of the program are tested and dog-fooded locally for days before I even upload them to github. I also use feature branches for "big" features so that I can fix bugs in master if I happen to discover them, while continuing to develop a feature in parallel. Because I don't have much free time to develop my personal projects, a big feature might take weeks or months to get merged in, but I'm not in a hurry!

</comment></comment></comment></comment></comment><comment><USER20> If one read Martin Fowler about feature branching, [https://martinfowler.com/bliki/FeatureBranch.html](https://martinfowler.com/bliki/FeatureBranch.html) and articles from Jez Humble both agree on that one should use trunk based development and use feature toggles in most cases for development.

<comment><USER15> Sure, do end up with hundreds of commits where any given combination of feature flags fails, except sometimes the default.

Seriously, this is the quintessential Gentoo Linux problem. Nobody can test all the combinations making the flags almost instantly useless. (And some essentially forced on.)

<comment><AUTHOR> Agree that feature flags count should not explode because you can never test all combinations. Feature toggles should drive the life span of a feature from start of development to "adopted and becomes the default" or "rejected and we scrap it all out". At the end of the day the number of feature toggles should remain relatively low.

</comment></comment></comment><comment><USER21> "Your feature branch is your own perfect garden and you can keep it clean and shiny. But it is separated from the other gardens of your team. The more you work apart, the harder it is to reconcile."

But then, later in the article,

"It is 2019. If you don't have a continuous integration setup that builds and runs tests automatically … then set it up yesterday. If you break anything you'll be notified before it becomes a problem for the whole team."

Which, in my experience, greatly helps to mitigate the "it works on my machine" factor that arises from having a new branch for each task.

I appreciate the perspective, but I've found working with feature branches much better than trunk-based development. I'll take my merge conflicts any day. :-)

</comment><comment><USER22> I've tried trunk-based development before, and while it provides certain benefits, I don't think it's a silver bullet.

> Why you should not use feature branches

> Keep reading, all the objections you can think of are wrong.

The tone of the title and some parts of articles suggests that trunk-based development is objectively better than feature branches. I feel that it's rather a matter of opinion. You might want to try it out, it might work better for you than feature branches. But I don't think saying "feature branches are wrong approach" or "your objections are not valid" is true for everyone.

One example are code reviews.

> If the code review culture is strong in your team then it can very well be > done on the commit to the main branch.

Personally I find this inconvenient. Reviewing a single commit does not show me the bigger picture. Let's say I refactor some code before adding a new feature. Refactoring is in a single commit, but to see whether this refactoring makes sense, it's better if the reviewer sees the next step, then they can understand better why I refactored it in this particular way.

> The main thing to improve here is probably not the branching model, but the > code review process.

Maybe this is true. Maybe my way of thinking about code reviews is wrong. However, again, I feel it's a matter of preference. I tried both ways and I certainly prefer reviewing the whole feature than single commits.

One more problem I find with trunk-based development: it happened to me before that a developer did something completely wrong. They misunderstood the requirement, they misunderstood the code - it happens, the world's not perfect. With feature branch I'll just ask developer to start from scratch. `git branch -D` and that code is gone. With trunk-based development the code is already in the master branch, and while it obviously can be changed or reverted, it's already there, people already have pulled this code, they modify this code, they look at it and try to understand it, they try to figure out why it's there.

Again, I'm not saying here that trunk-based development is a bad idea. It might be working for you, it might not, everyone's different. I believe the article explains the benefits of trunk-based development pretty well, I wish though it wasn't presented as an objectively superior alternative to feature branches.

<comment><AUTHOR> Fair enough. You have a valid point on "your objections are not valid" is not the right tone. I'll edit to highlight that feature branches have their benefits in some cases. Thanks for reading!

<comment><USER22> Thank you for considering my comment!

<comment><AUTHOR> I've updated the sentence with "Here are the common objections one might have and a tentative solution" and extended the conclusion to say "TBD is not the only way to work"

</comment></comment></comment></comment><comment><USER23> I just rebase my feature branches before merging. Keeps the tree more or less linear.</comment>


Show HN: Autogit - execute commands across all your repositories - <AUTHOR> https://github.com/fabiospampinato/autogit <comment><USER2> That seems like an interactive and slower version of mr?

[https://myrepos.branchable.com/](https://myrepos.branchable.com/)

<comment><AUTHOR> It's _optionally_ interactive, you also just write the command.

I didn't know about myrepos, thanks for sharing. Their capabilities are probably overlapping a lot, from what I can see there might be a few differences though:

\- autogit probably has a more beautiful CLI

\- autogit can perform actions on subsets of your repositories, not necessarily all of them

\- autogit's commands are configurable via JS plugins, myrepos's commands are written in bash (one could always just tell bash to run a JS file though)

\- myrepos caches the repos it finds, autogit searches them everytime

\- myrepos supports all kinds of repositories, autogit only supports git

I don't know about the slowness, I guess you're probably right since myrepos can run commands concurrently, I should add an option for this to autogit as well.</comment></comment>


Socialists and Libertarians – The Great Divide - <AUTHOR> https://firstname.lastname@example.com/socialists-and-libertarians-the-divide-7b5e19f0858a#.52ywb9qhb <comment><USER2> Bringing up some of these questions is valuable, but I don't see this article as being a particularly notable one. For starters, the major premise seems a bit inaccurate.

From a libertarianish/ancap perspective, I don't see the point about "libertarians believe in the fundamental good of individuals" as a particularly strong one as you can logically arrive at the same conclusion about wanting small (or no) government based on believing that humans are both fundamentally good or evil.

If humans were mostly good, you wouldn't need a strong government (or any government really).

And if people are not mostly good, why the hell would you want to give the biggest manipulative assholes and liars (politicians, in case you didn't guess) a big monopoly of power that's ripe for the best liars to try and capture and abuse?

You can arrive at the same conclusion regardless of where you fall on this question.

From a socialist's perspective, I believe you can arrive at the same conclusion about wanting a more interventionist government from both sides of this question as well. If humans are mostly good, a socialist could argue that having the power for the majority to help people is good. And if humans aren't mostly good, then a socialist would argue that having the power is necessary to help everybody make the right choices for their own good.

</comment><comment><USER3> Neglects to note libertarian socialism: [https://en.wikipedia.org/wiki/Libertarian_socialism](https://en.wikipedia.org/wiki/Libertarian_socialism)</comment>


Who is going to Startup Camp 2 on May/7 in SF? - <AUTHOR> http://startupcamp.org/ <comment><USER2> _'... So, what are the basic implications of an unconference that uses the Open Space methodology? ...'_

you might have to code in java, no make that 'java light' ~ <http://wiki.startupcamp.org/wiki/StartupCamp2DiscussionIdeas>

</comment><comment><USER3> That list of sponsors makes it look more like a job fair than anything to do with start-ups.

</comment><comment><USER4> Interesting and strange at the same time. Definitely thinking about going.

</comment><comment><USER5> I'll be there -- curious to see whether it's worth it or not. :-)</comment>


India - <AUTHOR> http://www.mauldineconomics.com/outsidethebox/raoul-pal-paying-attention/ <comment><USER2> This type of "field survey" article is great because it helps connect a bunch of different dots. The stories about India accelerating their digitization efforts is truly eye-opening and worth the read.

Considering this is a macro-economic investment article, I will call out that although going long on the Indian telecommunications sector seems like a good value play, over the short-term the entire Indian telco sector is experiencing turmoil[1] due to a recently sparked price war by 4G/LTE-only wireless network operator Reliance Jio who launched September 2016 and within 6 months signed up 100M subscribers by giving voice & data services away for basically free[2].

Hence, Raoul Pal's comment in section 7 about being long the telco sector makes sense, but choosing Bharti Airtel alone doesn't, given the intense competition and relatively recent consolidation.

[1] [http://telecom.economictimes.indiatimes.com/news/staff- stare...](http://telecom.economictimes.indiatimes.com/news/staff-stare-at-pay- cuts-in-shakeout-hit-telecom/57682185)

[2] [https://en.wikipedia.org/wiki/Jio](https://en.wikipedia.org/wiki/Jio)

<comment><USER3> This article is paid for by current Indian govt supporter or mr Raoul's knowledge is pretty limited. Govt spending is never efficient, we have seen first hand misuse of aadhar by Indian police and politician. All this digitisation in India is a farce trying to create a totalitarian state.

China has an active 600 million mobile wallets in use on regular basis by people as old as 75, including Mom and pop shop despite push by govt to reduce it, diametrically opposite to India, since transaction cost is 0 with daily interest credited for even 10 cents deposit. UNI is a step in right direction but paying 1-3% extra for just moving money is not efficient when the cost of moving digits is much lower, which is true for India. Paying 45% in direct tax and then adding additional tax will make Indian politicians more rich, they can move money offshore easily. This cash ban is boon for those industrialist who got more money to play from hard working middle and lower income groups in India.</comment></comment>


Macbook and USB-C Review - <AUTHOR> http://ma.tt/2015/05/macbook-usb-c-review/ <comment><USER2> > I think the most perfect tech combo in the world right now might be a 5k > iMac at home, an iPhone 6+ as your phone, and the Macbook as an on-the-go > device.

Unfortunately, you can't use a 5K iMac as an additional screen for a Macbook.[1]

[1] "Note that the iMac (Retina 5K, 27-inch, Late 2014) does not support Target Display Mode." From [http://s831.us/1bYWtfj](http://s831.us/1bYWtfj)

<comment><USER3> Nothing in the quote or article suggests using the 5K iMac as an additional screen, though. To my reading, the author was suggesting the iMac for working, and the Macbook for when you're on-the-go and (hopefully) not working.

Why would someone buy a 5K iMac to use it as a second display? That's what the standalone displays are for.

<comment><USER2> I like to keep my personal projects and software on my personal hardware and my professional work on my work supplied laptop.

When working at home, I like to use my work laptop with a second display. It seems unfortunate to have to buy a separate Thunderbolt display if I already own a 5K iMac.

<comment><USER3> Ah, fair enough. Definitely sounds like a 5K iMac would be a poor choice for your use case. Better to stick with laptops and a thunderbolt display.

</comment></comment></comment></comment><comment><USER4> I'm surprised his battery life is so short (5-6 hours). I have the base model MacBook and I easily get 8 hours. To go as low as 5 hours, I'd have to keep CPU usage at 100% and run the screen at max brightness.

If I focus on prolonging battery life, I can get 12 hours. That means keeping the screen dim, quitting Mail.app, and closing unnecessary browser tabs. Then the only major eater of battery is compiling stuff.

Overall, I really like the new MacBook. It's thin, light, and fast enough for my needs.

<comment><USER5> > I'm surprised his battery life is so short (5-6 hours). I have the base > model MacBook and I easily get 8 hours. To go as low as 5 hours, I'd have to > keep CPU usage at 100% and run the screen at max brightness.

If he's a Chrome user, I wouldn't be surprised. It seems Chrome doesn't sleep/isn't as aggressive at idling as Safari.

I've yet to spend a full day out on my machine though so I cannot confirm first-hand whether Chrome drains the battery so quickly.

<comment><USER4> I use Chrome, but I run maybe 10 tabs and have all plugins disabled. Safari's lack of WebRTC and general security issues (typically the first to fall at Pwn2Own) have scared me off.

It may surprise people to discover how inefficient some applications can be. It only takes one programming mistake to prevent the CPU from going into deep sleep. Even popular apps such as Spotify, Dropbox, and iCloud sync can fail in this manner and squander power.

</comment></comment></comment><comment><USER6> I'd love a MacBook. However, I am a bit concerned: is the maximum performance of it worse than the 2013 MacBook Air (current machine)? On this thing I can play Counter-Strike: Source or Left 4 Dead 2 at reasonable settings at 60fps, and I can also get FFXIV to run at just about 30fps (windowed 720p on Windows with the Standard (Laptop) graphics option). I'm not really a serious gamer, these are all (with the exception of FFZIV) older games I play casually. I mainly do web browsing and programming.

If I tried to do these things on the new MacBook, would it run at similar speed, and would I get a heat warning?

Ignoring gaming for a moment: generally, when really stressed, are heat warnings common?

<comment><USER7> There won't be heat warnings. It'll throttle itself back down to its base speed when it starts warming up.

So yes, the maximum performance _for an extended period_ will be much worse than a MBA.

<comment><USER8> > So yes, the maximum performance for an extended period will be much worse > than a MBA.

Get a life man!

<comment><USER8> So HN people don't see a problem when someone mocks a whole community, but are happy to downvote my comment.

I knew my comment was going down. I still had to take my stand and post it. But how come people don't see a fault with the original comment.

<comment><USER9> MBA = MacBook Air. Can the histrionics.

<comment><USER8> Damn! I'm sorry. Read it as Masters of Business Administration. Was on another thread where someone was commented on mbas. Over and out.

</comment></comment></comment></comment></comment></comment><comment><USER10> I don't see the single port as a big deal (it's clearly the future) but I would have expected a USB port on the power adapter (PlugBug-style) at least for power if not transmission.

<comment><USER5> No idea why you have been down-voted: it's a good point. having one AC brick with two plugs (USB-C, USB A) would be helpful for charging both the laptop and a phone simultaneously. Right now you can't do that due to the single port on the MacBook.

</comment></comment><comment><USER11> Honest question: once the Macbook reaches the (approximate) weight and convenience of the iPad -- and has touch input -- is there any future for the iPad?

Sure, iPads are more convenient for giving to kids, but a Macbook with a surface-style keyboard and touchscreen kind of moots that entire line.

I see tablets and the requisite limited tablet software/interface as a necessary evil we had to pass through before we could make full-fledged computers small enough to have the same convenience.

<comment><USER12> Why do you think it will have touch input? Apple seems fairly determined that laptops and tablets are different form-factors that work better with different ways of interaction.

I think there is definitely merit to this - Windows 8 showed how easy it is to get the hybrid approach wrong, and the gestures with the MacBook's multi-touch trackpads seem to me to be a better way than having to reach up to touch the screen all the time...

<comment><USER13> > Windows 8 showed how easy it is to get the hybrid approach wrong

On the contrary, a lot of people do find the hybrid approach very useful especially once they are accustomed to it. When travelling I take my Surface Pro instead of my laptop and by the time I am back, I am so used to touching and taping on my screen that I unconsciously do it on my laptop making me look like an idiot. I find touchscreens great and believe it is a means to complement your existing workflow, not replace it.

<comment><USER14> I agree. The hybrid touch paradigm is fantastic.

What Windows 8 did wrong was messing with the familiar old-school interface a bit too much, which made many non-tech-savvy users confused and miserable. My dad had a terrible time with Windows 8. But me? The Surface pro is easily among my favorite devices ever.

</comment></comment></comment></comment><comment><USER15> Given that I've never connected my iPhone / iPad to my Macbook Air, sounds like I might be a good target for this device.

</comment><comment><USER16> When I can fold over the keyboard behind the screen and read it like an iPad, then I will not need an iPad.

<comment><USER17> I know that lots of people are very Microsoft-averse, but this is exactly what the Surface is.

<comment><USER18> Surface is more of a _desk_ top than a _lap_ top though.

<comment><USER19> What is a laptop besides a portable desktop???

<comment><USER20> I think his point is that since it doesn't have a traditional hinge it's hard to actually use on your lap.

<comment><USER21> Have you tried the Surface Pro 3? It is easily usable on your lap.

<comment><USER18> The Surface is a computer for Serious Professionals who don't act so casually as to use a computer while lying in bed, or sit cross-legged on the floor, etc.

I'm sure that the Surface is a perfectly useful computer for some people, but I use my laptop in far too many odd positions to get along with one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> > The problem in one sentence: it is impossible to buy a cable, from Apple or > otherwise, that let's you plug an iPhone 6+ into the Macbook.

I'm not an Apple person by any means and don't really keep up with their products, but I feel the Apple of years past would never have let this happen.

<comment><USER15> Putting a different spin on this - it's very curious that Apple didn't release a USB-C to Lightning port cable. This was clearly a deliberate decision on Apple's part - and I'm wondering if they just decided that by released the USB-C to USB-A dongle ([http://store.apple.com/us/product/MJ1M2AM/A/usb-c-to- usb-ada...](http://store.apple.com/us/product/MJ1M2AM/A/usb-c-to-usb-adapter)) , that would be sufficient?

<comment><USER7> I've plugged my iPhone into my MBP twice, I think.

What will be interesting is what they do with the next model iPhone. I suspect we'll either just keep getting the USB-A -> Lightning cable or the iPhone will get a USB-C port (and come with a USB-A to USB-C cable?). The latter is inevitable, the question is 'when'.

<comment><USER23> Remember that lightning was designed specifically for the needs of the iPhone and the iPad, not computers in general. It wouldn't surprise me if Apple kept using it on the phones since it's not like there's a huge number of third- party parts that you might want to plug in.

I imagine lightning will be around for a while on the phones. It's still perfectly fit for purpose.

</comment></comment></comment></comment><comment><USER24> If he had a heat warning in LA, I worry about how the new MacBook will hold up in hotter climates (SE Asia, Middle East, etc.)

<comment><USER25> People rarely sit outside in the heat for a long time working on their laptops in SE Asia or the ME.

</comment></comment><comment><USER26>
       1. remove ability for people to use a cable to transfer photos
       2. force everyone to upload pics to icloud
       3. ????
       4. profit!

<comment><USER27> And if G or MS pulled the same, everyone would be yelling about antitrust...

<comment><USER26> lol. indeed!

but since it is apple, we get downvotes.

enjoy!

(btw, search online for the time --2007?-- that nokia forced the whole industry to microUSB, that every single phone uses nowadays, as the standard charger plug by being the first to mass adopt it. everyone cried charger monoply)

<comment><USER10> Thank goodness not "every single phone uses" the galactically stupid MicroUSB.

<comment><USER26> Yeah, 30 pin was much better option at the time.... btw, nokia moved away from a connector exactly like the 30pin one</comment></comment></comment></comment></comment>


How to Get Your Startup Idea Funded by Venture Capitalists - <AUTHOR> http://www.google.com/events/io/2011/sessions/how-to-get-your-startup-idea-funded-by-venture-capitalists.html

<comment><USER2> There's nothing on this page but an announcement for a presentation that's happened in the past. Did I miss a video link somewhere?

<comment><USER3> You are not alone. I wish I had enough karma to downvote.</comment></comment>


Don't be so quick to embrace your own ignorance. - <AUTHOR> http://www.37signals.com/svn/posts/1187-dont-be-so-quick-to-embrace-your-own-ignorance

<comment><USER2> I never bought any of these Dummies books, for a similar reason. I don't think I'm a dummy, or an idiot, and I take it as a personal insult. If you want to sell a book to me, don't call me an idiot.

Yes, I know it's just a joke, but to me, it's a poor, insulting, and, most of all, an idiotic joke. Perhaps the authors think of themselves as idiots. Why should I read them?

I'd much rather buy from a "For smart people" series. It's a shame no one publishes that.

<comment><USER3> [http://www.amazon.com/Joe-Celkos-SQL-Smarties- Programming/dp...](http://www.amazon.com/Joe-Celkos-SQL-Smarties- Programming/dp/1558605762)

It's socially acceptable, even desirable, to lack technical skills. Witness the number of people who will happily proclaim they're no good at maths or whatever. Western culture (presently) doesn't value effort or accomplishment - you're supposed to succeed "just for being you", like a reality TV star, pop idol, etc. History will not reward this decadence.

</comment></comment><comment><USER4> _While there are probably plenty of geniuses out there, most of the interesting people I've talked to are of average intelligence, but above- average aspiration. Stop believing in the myth of triple-A people as a different kind._

Whenever I start feeling frustrated on some endeavor of mine, I try to pause and remember this principle.

</comment><comment><USER5> This kind of ties in with pg's essay on amateurs.

aside: pretty funny how dhh marks trolls in his comments - a dunce hat with 'troll' written on it. Ouch.

<comment><USER6> Heh, that's very clever. Although one wonders if the trolls feel like they have been vindicated in some way (by being able to draw attention!)

<comment><USER4> I rather like the "disemvoweling" used over on BoingBoing. It's a good balance between just deleting trolls and giving them too much attention.

The color fading used on HN is a good technique too.

<comment><USER7> Disemvoweling tends to pique my curiosity. I'd like to puzzle out what's said and see what they were disemvoweled for. I think the color fading is a better technique for this reason -- there's no mystery, only muting.

</comment></comment></comment></comment><comment><USER8> I always get a laugh out of the "Income Tax For Canadians (for Dummies)" whenever I am at the bookstore. It's just a regional version of a generic book, but the "for Dummies" part is in a pretty small font.

</comment><comment><USER9> I think the "for dummies" is both humorous (as much so as a how-to book can be) and descriptive. It's good to embrace your ignorance, that's the only way to cure it.

<comment><AUTHOR> I always felt that "for people too busy to spend years" on the subject at hand would be a more apt description.

<comment><USER9> Too long, and lacking any sort of self-deprecating humor.

<comment><USER7> The "Been Too Busy For [X]" books would probably sell well to pointy-haired boss types who have big egos and just want the "10,000 foot view."</comment></comment></comment></comment>