Woodcut Maps: Handcrafted wood-inlay maps, designed by you - <AUTHOR> http://woodcutmaps.com

<comment><USER2> Cancun is a "designed" city and the core districts are laid out inspired in Mayan hieroglyphs. This makes terrible urbanism but some pretty sweet woodcut maps. <http://woodcutmaps.com/11254>

<comment><USER3> That is amazing.

Look at DC, which is the exact same thing - but with masonic symbolism rather than mayan symbolism.

<comment><USER4> Notice you do not link to a map. Because this is total bullshit. [http://rationalwiki.org/wiki/Washington,_D.C._street_design_...](http://rationalwiki.org/wiki/Washington,_D.C._street_design_conspiracy_theory)

<comment><USER3> Sorry, but the way they refute is is to say "the street does not extend to a point" yet you can draw the symbol on the streets and see that the design is perfectly implied.

[http://maps.google.com/maps?q=washington+dc&hl=en&ll...](http://maps.google.com/maps?q=washington+dc&hl=en&ll=38.903758,-77.035489&spn=0.014544,0.033023&sll=37.0625,-95.677068&sspn=59.639182,135.263672&hnear=Washington,+District+of+Columbia&t=m&z=16)

I also assume you're not a Mason, thus you think that everything is simply coincidence.

Sorry - but there are very deliberate decisions, particularly with respect to design, that are, in fact, Masonic, all over DC.

</comment></comment></comment></comment><comment><USER5> For the curious: Default is $105 for an 8"x8" map. 20"x16" is $350. It appears that wood species choice has no impact on pricing, but I didn't want to abuse their render queue with any more experiments. :)

Also, to the creators - it would be great to have a "pricing" page to explain this!

<comment><USER6> Good idea, will do. Right now for simplicity's sake we just have the wood species not affect pricing even though they greatly vary in cost to us. We're coming out with some really gorgeous burled woods soon that are a bit pricier -- we'll probably add variable pricing based on wood species once those choices are available.

<comment><USER7> Offtopic: Why do you use two accounts on HN, _gabesmed & gabesmed?

<comment><USER8> No-procast: <http://news.ycombinator.com/item?id=3763855>

Edit: Longer version: It is because of his noprocast setting.

<comment><USER9> I was impossibly confused until I realized you meant to write "noprocrast". As in "no procrastination".

<comment><USER8> Thanks for pointing that out! I don't think I have ever written the word procrastination myself, so wasn't even aware of the spelling mistake I made.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> I'd love to hear the dev talk about the architecture of this service – there's nice work for the site itself with queued renderers, and apparently back-end work to generate the laser-cutting instructions.

More on the process: <http://woodcutmaps.com/process>

<comment><USER10> Heya, I'm the developer behind Woodcut Maps!

The site is built on python/django and hosted on AWS.

Most of the interesting work happens in python with PIL, numpy and scipy. We download maps tiles (Google for now, working on an OSM render path), and split them into channels for landscape, water, roads and parks. Then we apply several steps of scipy's image morphology filters to get the masks ready for laser cutting and to ease assembly by simplifying the design. Removing small pieces, filling small gaps (which gives the maps the distinctive look of dense roads being filled in, creating chunky blocks), and simplifying boundaries.

All the rendering happens on picloud.com, which has been a really robust part of our infrastructure. It helps us scale up and down based on demand without having to manage an autoscaling AWS backend processor setup ourselves, or overpay for AWS instances.

I'm probably going to talk more in detail about it at WhereCamp this weekend if anyone wants to talk in person.

<comment><USER11> This is a bit out of scope but I would _love_ to have a similarly crafted version of john snow's classic cholera map.

<comment><USER6> Oh we could totally do that. One color for roads, one for bars, one for background. We could probably do Minard's Napoleon's March map too (minus the labels) just for fun. <http://www.edwardtufte.com/tufte/posters>

</comment></comment></comment></comment><comment><USER12> Wow, that is really cool. If I could come with a small feature request, I'd love to see support for open street maps as well. At least for the area around my house OSM has much more detailed maps. Google maps for example doesn't have the road that leads up to my apartment building, since you can't drive on it, while OSM does.

<comment><USER10> We're actively working on an OSM render path. Coming soon!!

</comment></comment><comment><USER13> Started out thinking that this was more parquetry than what I imagine is called 'woodcut'. Turns out it's probably marquetry instead. All from Wikipedia:

"Parquetry is a geometric mosaic of wood pieces used for decorative effect."

"The use of curved and natural shapes constitutes marquetry rather than parquetry."

"Marquetry (also spelled as marqueterie) is the art and craft of applying pieces of veneer to a structure to form decorative patterns, designs or pictures."

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

And, so I learned something new.

<comment><USER10> Yup. The working title for the project was 'mapquetry'. Though technically inaccurate, Woodcut Maps is way catchier.

</comment></comment><comment><USER14> Would it be possible to provide a data format by which one could upload custom inlay layers to produce a design of his choosing? I'm thinking specifically about a silhouette photograph I shot of my son. Is there a way to validate the manufacturability of an arbitrary layer set?

<comment><USER15> I'd like to have a little more control, so I could fit, say, Yosemite Valley in the 5x16 by rotating the map a little.

<comment><USER6> We can't do rotations..but a hidden pro feature is you can drag the gray frame in the google maps interface to zoom in and out precisely.

<comment><USER16> The mouse-over pointer change is a well chosen hint and the affordance is fairly obvious. Nicely done.

</comment></comment></comment></comment><comment><USER17> This is probably the most interesting company I have read about on this site. The love using software to make something physical. I will definitely consider a purchase in the future.

</comment><comment><USER18> This is so great. Is your backend set up to do other vector paths besides just map tiles?

<comment><USER6> Yup. The settings are tuned for maps right now, but we can take any raster image with up to four b&w layers and send it through the same process.

<comment><USER3> Whats the max size?

What if I want a rooms floor done like this?

<comment><USER10> Then I would personally salute you. Still trying to convince the fiancee to do our living room as a woodcut floor :)

<comment><USER3> I'd like to try some Escher patterns.

I have been drawing some based on some of his drawings in AutoCad - to then color in illustrator.

I drew this the other day - and it would be great to do a pattern like this in wood for an entryway:

<http://i.imgur.com/CMa4J.png>

</comment></comment></comment></comment></comment><comment><USER19> shut up and take my money!

i want something with WAY more detail on how it works. like, i understand laser cutters and whatnot, but this seems harder. can you write more up?

<comment><USER10> I'll be preparing a preso for WhereCamp this weekend; I'll definitely put it online as well.

<comment><USER19> That would be awesome.

</comment></comment></comment><comment><USER20> Having done my fair share of laser marquetry, let me first tell you that I truly appreciate the amount of work that goes into the whole process, and really respect what you are doing. The intricacy of these types of patterns makes for a very high level of difficulty.

That being said, it appears to my somewhat trained eye that you are using Photoshop (or other CG) mockups on some of the product pages (<http://woodcutmaps.com/146> for example), without saying explicitly that that's what they are. I know how difficult straight on photography is with these textures, but if those are indeed Photoshop generated, you run the risk of increasing expectations beyond what is technically possible with the process.

Excellent work either way, as I can tell from the genuine product shots. Like I said, not easy stuff.

</comment><comment><USER16> 1) These are fantastic. 2) Surely this is breaking the Google Maps licence for use of their map tiles? Switch to OpenStreetMap!

</comment><comment><USER21> I'm getting an OVER_QUERY_LIMIT error:

      GeocoderError at /create

      Error OVER_QUERY_LIMIT
      Query: http://maps.google.com/maps/api/geocode/json?region=&sensor=false&bounds=&language=&address=

Also, you should want to change your Django DEBUG setting to False

<comment><USER6> Haha, you caught a little live debugging. Should be fixed now.

<comment><USER21> Sorry about that.

Otherwise great work, these look amazing!

</comment></comment></comment><comment><USER22> To the creators: Great job guys! I just ordered a map as a gift. I would have loved to carve a date or write a few words on the map though.

I found the entire process of ordering a breeze. However, I feel that the payment process should be improved - 1\. PayPal forced me to sign into my obsolete paypal account due to same email id. 2\. It showed me an annoying advertisement to sign-up for their debit card program. 3\. It assumed my address was the shipping address. 4\. I did not see an option to send this item as a gift.

I hope you guys keep getting bigger and better.

</comment><comment><USER23> Cool idea! Here's a product my ad network manages the promotion for that is quite similar: <http://go.chaseclicks.net/SHHK>

There isn't as large of a variety of woods, but there is good flexibility in pricing, size, and it's more for photographs and keepsakes than a map of an area.

Also, not trying to detract from your post by sharing this other product, just thought it was very similar and thought I'd share. Looks like a well thought out system and business model! Best of luck!!

</comment><comment><USER24> Very cool idea; all I can get however is "Sorry, something went wrong. We've been notified and are on the case!" (I'm trying to get maps from France).

<comment><USER25> I seems that it does not like non-ASCII characters (got the same error when I searched for Swedish cities). Try searching for the English name of your city or, if such a name is not available, a neighboring city that has and then scroll the map to the place you'd like to see.

</comment></comment><comment><USER26> I love the idea and service. Congratulations.

</comment><comment><USER27> Brasília is also a "designed" city, and the woodcut maps are awesome: <http://bit.ly/Hi9m09>, <http://bit.ly/HcBdSB> and <http://bit.ly/GXK5Lv>.

</comment><comment><USER28> Centered on Y Combinator: <http://woodcutmaps.com/13111>

Google: <http://woodcutmaps.com/13154>

</comment><comment><USER29> beautiful. @gabesmed is the wood sustainable & ethically sourced?

<comment><USER30> Allow me to hijack the discussion ever-so-slightly and point out that imported wood is now a Big Deal, and potentially very dangerous to work with, due to recent expansions of the Lacey act. You may have heard of the case of Gibson Guitar:

\--

"They...come in with weapons, they seized a half-million dollars worth of property, they shut our factory down, and they have not charged us with anything," says Gibson Guitars CEO Henry Juszkiewicz...

The feds raided Gibson for using an inappropriate tariff code on wood from India, which is a violation of the anti-trafficking statute known as The Lacey Act. At issue is not whether the wood in question was endangered, but whether the wood was the correct level of thickness and finish before being exported from India. "India is wanting to ensure that raw wood is not exported without some labor content from India," says Juskiewicz."

[http://reason.com/blog/2012/02/23/the-great-gibson-guitar- ra...](http://reason.com/blog/2012/02/23/the-great-gibson-guitar-raid-months- late) (disclaimer: Libertarian news site is a partial source, interpret that partiality as you will. other sources and commentary exist. many of them are probably better, this was just convenient because I remembered it and could google it quickly. you should look up these other sources if you're interested!)

\--

The cynics suggest that this is all at the behest of the Pacific Northwest domestic timber lobby, using environmental sentiment to dampen competition from overseas. Gibson's case, by that theory, is a deliberate scare tactic designed to create a chilling effect.

And to bring the discussion back to the matter at hand: whatever you're doing, I _hope_ you're aware of all this, and documenting everything you have meticulously, or you could end up screwed. Like, possibly-in-jail screwed. For working with wood veneer. Believe it.

<comment><USER29> _"... point out that imported wood is now a Big Deal, and potentially very dangerous to work with ..."_

Shipping timber has consequences. Tall timber, hardwood in particular is the flora equivalent of the Rhino, Elephant and big Cats. Hunted to extinction, chopped up, chipped & poorly used.

 _"... The woodlands & forests that had once ringed the entire Mediterranean & provided a home for a rich population of animals had now largely gone. They survived only places for which no soldier bothered to fight, where no forester found it possible to haul out timber, & no farmer thought it worthwhile to make a field. ..."_ David Attenborough, _"The First Eden: The destruction of the forests"_ , Pt3, p173.

Learn the lessons of the past.

</comment></comment></comment><comment><USER31> I might show my ignorance for the complexity of the process here, but here goes: Why is laser cutting from prefabricated digital prints considered "handcrafted"?

<comment><USER10> Our oboist team member, who hand-carves her own reeds, assembles and finishes each map by hand.

<comment><USER32> Finally, an oboist who found their burden to be useful in life outside music!

Would be great to see some footage of one of your maps actually being made some time.

<comment><USER16> Hand carving your own reeds appears to be a rite of passage as an oboist (my wife plays).

</comment></comment></comment></comment><comment><USER33> Call me a tree-hugger, but I was hoping that recycled wood was used, and that my greedy desire for one of these would not result in rainforests being destroyed. It would be nice to know if this service was green, too.

"Zebrawood is considered a threatened species in its native habitat. Its fast- growing popularity in the West has resulted in some reforestation efforts, but these are not keeping up with the pace of harvesting." <http://en.wikipedia.org/wiki/Zebrawood>

<comment><USER34> Ugh. Treehugger.

Being from a lumber producing area, the whole concept of "recycled wood" really annoys me.

Old wood breaks down, causing no waste.

"New" wood is produced on farms. Exactly like corn and soybeans, but with much longer crop cycles. Just like other cash crops, if you remove the demand for new wood, Weyerhaeuser will cut down all the trees and plant something else that makes money or sell off the land for urban development.

All of the major concerns with commercial lumber production have been mitigated with smarter land management practices and technology. All of the "old growth" forest that environmentalists like to jump on is actually pretty impractical for large scale commercial operations to deal with, and protected by existing laws anyway.

Some species (like Zebrawood as you mention) are threatened by initial commercial exploitation, and sadly the biggest offenders are indigenous farmers. Once a wood becomes commercially viable the big players move in with established reforestation and resource management policies that actually help to stabilize the situation (because they can't make money long term off an extinct species).

</comment></comment><comment><USER35> This is an amazing tool, but unfortunately incredibly uninteresting because I live in the suburbs!

</comment><comment><USER36> You should add a +1 button on your site, I had to copy/paste the link manually :).

</comment><comment><USER37> Beautiful work! What kind of finish is used to seal and protect the final piece?

<comment><USER10> It's called Emmet's "The Good Stuff" - a gel urethane that gives a nice warm glow to the wood, is easy to apply, quick-drying, and not unpleasant or dangerous to breathe. (we work out of our cottage, so no professional ventilation systems for us!) <http://www.mapleblock.com/detail/butcher-block- finishes-39/>

</comment></comment><comment><USER38> Are there copyright issues with using Google's maps?

<comment><USER30> And on that note, allow me to encourage you to consider the copyright issues and the possibility of using OpenStreetMap instead.

Edit: looks like another comment has since been posted which talked about 'working on an OSM render path', there you go

</comment></comment><comment><USER39> I wanted to make a purchase, but your web site is turning into a perfect infinite loop to PayPal. It just keeps trying to forward me to PayPal, abort, retry..abort..retry

Fix your code and you get the money?</comment>


A Corporate Strategist's Guide to #Blockchain Use Case Design and Execution - <AUTHOR> https://www.linkedin.com/pulse/strategy-students-guide-exactly-why-dlt-big-deal-ajit-tripathi?published=t <comment><USER2> +1 phenomenal insights here.</comment>


Show HN: Coinpare – Compare cryptocurrency trading data in your terminal - <AUTHOR> https://github.com/piotrmurach/coinpare <comment><USER2> Nice, I like the watch parameter where you can set the poll time. Do you have any support for websockets? If not, do you plan on implementing websocket support for exchanges?</comment>


Spatial-Temporal Recreation of Android App Displays from Memory Images [pdf] - <AUTHOR> https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_saltaformaggio.pdf <comment><AUTHOR> TL;DR The researchers claim this is a new memory forensic method to gather information from recently used apps from Android devices. Instead of extracting GUI-data from memory images, they extract app-internal data from them (which persists longer than the GUI-data) and restore the View from that data. With this method they can recreate multiple views in the past instead of only one if GUI-data is targeted directly. The method is app-agnostic and doesn't need any knowledge about the targeted apps. They tested their attack against at least 15 apps with success.

They call their method "RetroScope", sourcecode of their forensic tool can be found at Github:

[https://github.com/ProjectRetroScope/RetroScope](https://github.com/ProjectRetroScope/RetroScope)</comment>


Ask HN: Have you shifted your hours for better productivity? - <AUTHOR>

I've been working a full-time job and trying to get some Web development done.
My typical day was something like: - Wake up at 7, get the kids ready (one off to school) - School drop off by 8:30 - At work by 9 - Home by 6 - Family time, dinner - Work on Web project from 8-midnight.
Needless to say, those last 4 hours aren't the most productive!  Recently I've tried going to bed at 9:30 and up by 4am. A good night's sleep seems to be working. Anyone else becoming an early bird? <comment><USER2> I did this for a while when I still had a day job. I found that I was much more productive _before_ spending 8 hours at a cubicle, so I went to bed at 9:30 and woke up at 6:30, then got 2 hours or so in before I had to go to work.

I've found it's not as helpful now that I've gone full-time, because my productive times tend to rotate around the clock. It'll be 10:00 AM - 2:00 PM for like 2 weeks, then suddenly shift to 10:00 PM - 2:00 AM, then come back to 4:00 PM - 9:00 PM (which is where it seems to be now, so I should get back to work).</comment>


YUI Version 2.2.0 Released - <AUTHOR> http://yuiblog.com/blog/2007/02/20/yui-220-released/ <comment><USER2> Bit old news isn't it? I've been playing with this since march.

It's good stuff, especially the CSS files make it easy to really define what you want. Not as sure about the javascript, myself, but then I haven't used it as heavily. I tend to just go with bare-metal javascript as/when needed.

<comment><AUTHOR> _'... Bit old news isn't it? I've been playing with this since march. ...'_

the release news is, but quite a few yc companies use the api so it might be of interest. nice thing with this set of tools is a) open source and b) not dependent on a closed service. what do you use for calendering? (showing 'foo' items on a particular date?)</comment></comment>


When to kill your tech startup - <AUTHOR> http://www.dirkdekok.com/2011/09/when-to-kill-your-tech-startup-lessons-learned-from-helloinbox/

<comment><USER2> I think this is an incredibly interesting post.

Point of reference: My background is in software product management at Bay Area startups, and then I went to go get my MBA (finishing soon... hopefully...).

I mention the MBA thing because in my entrepreneurship classes, I'm often the only one saying that X should keep going with their business even when things aren't looking too bright (I've found that most MBAs natural inclinations are to exit a business because being making a startup work is exponentially more difficult).

With that being said, I think it takes a tremendous amount of maturity and awareness to know when to kill your startup. Personally, I think this makes you a better entrepreneur, and I wish you the best of luck on whatever you attempt next.

<comment><USER3> thanks! yes moving on, taking all the experience with me. Next startup will be better!</comment></comment>


Show HN: Clio Programming Language - pouya-eghbali https://github.com/clio-lang/clio <comment> pouya-eghbali Clio is a pure functional lazy-evaluated programming language targeting decentralized and distributed systems. It is made to take advantage of multiple CPUs and CPU cores (parallelism) by default, to run on clusters and on the cloud easily.

Link to github project: [https://github.com/clio- lang/clio](https://github.com/clio-lang/clio)

My goal is to get feedback and your opinions on this language, I thank you in advance for your interest and support!

<comment><AUTHOR> Why is running on the cloud something that needs to be confronted at the language level?

<comment> pouya-eghbali Clio has a network-based approach to parallelism. It compiles to JS and uses Node to run the generated JS code, so just like Node, it is single threaded. Having a specification for remote calls gives us a few benefits, for example:

1\. We can use async remote function calls to run several tasks simultaneously. Why block and wait for the results when we can request the next one? This way you can also use resources on other machines on the network. This solves the single threaded only issue.

2\. We can use functions and some libraries of other languages

I also wanted to make these simple tasks easier for the developer. 20-30 years ago things didn't work like now, today we have new concepts: serverless, cloud, saas... now things are different and it's nice to have some helpers in the core. I actually started working on this project because of the difficulties I had with C/Python/JavaScript when I was making a cloud heavy app.

One more reason for this is that I want to encourage our users to write smaller independent and interconnected programs instead of making a giant monolithic app. This helps a lot with maintainability and portability.

</comment></comment></comment><comment><USER2> Could you provide more and bigger examples e.g. a small REST Microservice?

<comment> pouya-eghbali There is a simple to-do list app here: [https://github.com/clio-lang/clio- todo](https://github.com/clio-lang/clio-todo)

It uses the microservices and web socket imports. To run it you'll need rethinkdb. Maybe I can host it for you if you want to see how it works? Also, if you want to see another specific example, I can make it. What would you suggest?</comment></comment>


Major Outage Prevents Purchases on Apple's iTunes & App Stores - <AUTHOR> http://www.macobserver.com/tmo/article/major-outage-stops-purchases-on-apples-itunes-app-stores <comment><AUTHOR> As of 12:30 AM EDT, can't download, update, or restore anything on iOS or Mac.

D'oh!</comment>


Pod Castaway: My Search for Podcasting Fame and Fortune - <AUTHOR> http://geni.us/podcastaway <comment><USER2> Now, this is quite interesting.

Seven reviews, all done _today_.

 _Six 5-star_ reviews, all done by _non-purchasers_.</comment>


So you want to be a developer? - <AUTHOR> http://www.blonde.net/blog/2015/04/16/so-you-want-be-developer

<comment><USER2> > If I see someone list HTML, DHTML, XHTML and HTML 5, alarm bells start > ringing

I understand where this is coming from, but I think the author should realize that lots of companies have non-technical people (or robots) screening resumes and they're looking for exact matches. You're a Phonegap expert? Sorry we need someone who knows Cordova. Its better to overlist than underlist.

<comment><USER3> Non-technical people screening resumes is a major dysfunction. If a company screens out my resume because I didn't include DHTML, they've screened themselves out--I wouldn't want to work at a place where the other members of my team are determined by someone unqualified.

Remember that there are more development jobs than there are developers. As such, don't act desperate. Companies want to control the job market by setting the expectation that they are interviewing you--don't fall for it. They need you more than you need them: you should be interviewing them.

<comment><USER4> > I wouldn't want to work at a place where the other members of my team are > determined by someone unqualified.

But it's a big firm, they've got to comply with both UK employment law and the German rules too.

They get 1000s of applications, so they need to filter them, it's time that's far to important to spend on a developer, I mean they are short of them too.

So I'll stick it on, probably in a format that makes it obvious to a technical person, I consider this an expansion of the bullet point technology.

<comment><USER3> > But it's a big firm, they've got to comply with both UK employment law and > the German rules too.

I don't know why this would be relevant. Excuses for why they are dysfunctional don't change the fact that they are dysfunctional.

> They get 1000s of applications, so they need to filter them, it's time > that's far to important to spend on a developer, I mean they are short of > them too.

It doesn't matter how many applications a big company receives as a whole. If you've posted a job posting for a specific job, you're lucky to receive 10s of applications, let alone 1000s. And given that a hire will affect the productivity of the team every second of every day for years, spending an hour filtering applications is absolutely a worthwhile investment of developer time.

And if applications are handled at the corporate level for a large corporation, the hiring process is fundamentally broken. That doesn't mean it's okay to have unqualified people filtering applications, it means that you should be posting jobs for specific teams rather than for the whole company.

I've worked at large companies where applications were filtered by a central office and it showed in the quality of applications we received. I ended up drawing from my local community instead and this was a big part of why our team outperformed others at the company.

> So I'll stick it on, probably in a format that makes it obvious to a > technical person, I consider this an expansion of the bullet point > technology.

You're only doing yourself a disservice by catering to organizations with crappy hiring practices. Good luck!

<comment><USER4> > You're only doing yourself a disservice by catering to organizations with > crappy hiring practices. Good luck!

I'm a CTO of a multi million pound firm now. But it did work for me very well when I was just a developer. I wouldn't be so quick to write it off.

Some of the big firms I've worked for absolutely did get hundreds of applications each day for jobs, especially ones aimed at graduates. They can afford to take the risk of missing a good candidate because they had T-SQL, but not SQL.

<comment><USER3> > But it did work for me very well when I was just a developer.

I'm not sure how you arrived at this conclusion. I'm sure you had no problem finding jobs, but that doesn't mean they were the best jobs or that it was due to your applying strategy. Casting a wider net won't necessarily ultimately lead to you having worse jobs, but it will at least cause you to waste more time on interviews.

> Some of the big firms I've worked for absolutely did get hundreds of > applications each day for jobs, especially ones aimed at graduates.

I'll venture that _every_ big firm gets hundreds of applications. This is completely irrelevant to my point, which is that handling applications at the corporate level is the wrong way to handle applications.

> They can afford to take the risk of missing a good candidate because they > had T-SQL, but not SQL.

And I can afford to be missed by such companies. I am _happy_ to be missed by such companies. I want to work with talented, motivated programmers, not people who made it through a non-technical HR screen.

<comment><USER4> > I want to work with talented, motivated programmers, not people who made it > through a non-technical HR screen.

The problem is, this sounds good, but in reality the world doesn't work like this. Hiring is complex, there are many legal implications of the interview process, I had to correct one of my employees just yesterday because he said the word "young", this is a big no no in the UK, we can't look for a "young person". I had to clarify and expand that he meant this is an entry level position designed for people looking to get exposure to certain technologies in an environment that will foster their ambitions and provide opportunities for growth as we expand. Fun this stuff isn't it, few developers want to learn these rules.

This is why in large firms you end up having to let HR handle things. No one is going to ask us, why out of our 12 employees, we've no one who is transgender, but if we had 1000 people, we would need to demonstrate that it's entirely because we haven't had anyone apply, not because we have turned them all down.

As firms get larger, responsibilities get divided into lines that are more immutable, sadly this will mean the person doing the first stage of the hiring probably knows nothing about computer science, but may well have an excellent understanding of team psychology and HR laws.

When I read a comment like your last one, I find it slightly saddening, it reminds me of being in Hong Kong last month, a friend of mine wouldn't even try the pickled ducks tongue, I've no idea why, he eats pate, but outright refused to even take a bite. I fear you are talking out of complete ignorance.

There are some teams in the big corporate firms that I'd rather quit (and have done!) than join, but there are also ones where I've worked with some of the best developers, mathematicians and scientists I've ever met, that's a fairly high bar. One in particular had a 'cap' of £250k per year for a developer, to give you an idea the average price is £60k. This big finance firm realised the value the right developers have, the money was symbolic, we had budget for anything we could remotely justify (PCIe SSDs when they were unheard of etc) we had very good levels of autonomy too, with a relaxed working environment, even if other people on other floors were wearing suits. I've also worked for a 'brogrammer startup' that I ended up quitting swiftly as they were breaking the law. I wouldn't project my experiences out to the whole set, only keep in mind that there are interesting opportunities everywhere, understand their barriers and obviously tailor my CV to fit each application.

It is foolish to write them all off, and frankly portrays that element of dismissing something you don't understand, which I find to be very poor trait for an engineer.

<comment><USER3> > The problem is, this sounds good, but in reality the world doesn't work like > this.

"The world" is quite a large thing to make claims about. It certainly works like I describe at some companies.

> Hiring is complex, there are many legal implications of the interview > process, I had to correct one of my employees just yesterday because he said > the word "young", this is a big no no in the UK, we can't look for a "young > person". I had to clarify and expand that he meant this is an entry level > position designed for people looking to get exposure to certain technologies > in an environment that will foster their ambitions and provide opportunities > for growth as we expand. Fun this stuff isn't it, few developers want to > learn these rules.

So your dev said something ageist and you taught them how to rebrand it? I'm really not seeing how this supports your point. If HR screening is just a way to cover your ass because your staff are bigots, I'm even more happy to be screened out by your HR department.

> As firms get larger, responsibilities get divided into lines that are more > immutable, sadly this will mean the person doing the first stage of the > hiring probably knows nothing about computer science, but may well have an > excellent understanding of team psychology and HR laws.

What this boils down to is "this is the way it's done, so this is the way it should be done".

If you hired developers that embraced diversity in practice rather than in appearance, you wouldn't have to have such an understanding of HR laws. It sounds like you're so caught up in solving this legal problem that you don't realize you have an _actual_ problem.

To address your concern about demonstrating that you didn't receive any transpeople's applications: I'm not saying you shouldn't keep records of who applies. I'm sure you can figure out a way to keep records of who applies without having HR decide which applicants are considered.

> When I read a comment like your last one, I find it slightly saddening, it > reminds me of being in Hong Kong last month, a friend of mine wouldn't even > try the pickled ducks tongue, I've no idea why, he eats pate, but outright > refused to even take a bite. I fear you are talking out of complete > ignorance.

On the contrary, I've worked at firms like the ones you've described, and that's exactly why I despise your way of thinking. I've experienced plenty of it and it's toxic.

> There are some teams in the big corporate firms that I'd rather quit (and > have done!) than join, but there are also ones where I've worked with some > of the best developers, mathematicians and scientists I've ever met, that's > a fairly high bar. One in particular had a 'cap' of £250k per year for a > developer, to give you an idea the average price is £60k. This big finance > firm realised the value the right developers have, the money was symbolic, > we had budget for anything we could remotely justify (PCIe SSDs when they > were unheard of etc) we had very good levels of autonomy too, with a relaxed > working environment, even if other people on other floors were wearing > suits. I've also worked for a 'brogrammer startup' that I ended up quitting > swiftly as they were breaking the law. I wouldn't project my experiences out > to the whole set, only keep in mind that there are interesting opportunities > everywhere, understand their barriers and obviously tailor my CV to fit each > application.

I don't disagree that there are great devs on dysfunctional teams. There are even non-dysfunctional teams at large firms (

> It is foolish to write them all off, and frankly portrays that element of > dismissing something you don't understand, which I find to be very poor > trait for an engineer.

Why is it that you assume I don't understand it? Could you consider that maybe I do understand it but I value different things than you? It sounds to me like we've got differences of values, not different levels of experience.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> I think a more accurate title would be "So you want to be a _web_ developer". I'm not sure much of that is accurate for other software disciplines.

<comment><USER6> There's other kinds of developers left? /s

<comment><USER7> Hi, I'm the enterprise over here!

<comment><USER6> Lies. Everybody knows there are no enterprise developers any more. /s</comment></comment></comment></comment>


Build your own filesystem, hellowordFS.c in 100 lines! - <AUTHOR> http://fuse.sourceforge.net/helloworld.html

<comment><USER2> FUSE has been around for a while, it is really a great piece of software. Especially the many different language bindings make it interesting.

Here is one for instance in Ruby (Hello World) [http://www.debian- administration.org/article/Creating_Filesy...](http://www.debian- administration.org/article/Creating_Filesystems_with_Ruby__and_FUSE)

Only disclaimer, as it runs in Userspace it's quite a bit slower than its kernel space twin.

<comment><USER3> Not too much slower (well, you're bringing Ruby into the picture, so maybe it is after all ;).

According to [1], NTFS-3G (FUSE) is basically on par with XFS (native), only slightly slower on rewriting. ZFS on FUSE reads almost as fast and lacks in write speed, which is reasonable---it's not optimised in the slightest and ZFS has a reputation for being somewhat slow even on Solaris, where it is native. Not too shabby, I think. (It's a benchmark, though. Your mileage may vary.)

1: [http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to- zfs-f...](http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to-zfs-fuse-for- fuse-performance/)

<comment><USER4> No, FUSE is really slow, it just depends what you're benchmarking.

That guy is really benchmarking the disk, not the filesystem. If you benchmark things that test the filesystem layer on its operations---that is, make it do lots of things to metadata but not read or write much actual data---FUSE gets the crap beaten out of it.

As an example, write a no-op filesystem in FUSE and a no-op filesystem under the VFS, and run postmark[1] on it. You should get some pretty drastic results.

My professor has something called FiST[2] (like yacc for filesystem devs) that gets about 1-2% overhead over a native FS, and I believe one of his papers contains a comparison with FUSE that shows how bad FUSE is, but I don't remember it.

[1]: <http://www.shub-internet.org/brad/FreeBSD/postmark.html>

[2]: <http://www.fsl.cs.sunysb.edu/project-fist.html>

</comment></comment></comment><comment><USER5> On the topic of fuse, I'll just take a moment to shamelessly plug mp3fs, a filesystem I wrote:

<https://bitbucket.org/stucchio/mp3fs/>

       $ ls music
        01 Ghosts I.flac  03 Ghosts I.wav  mp3file.mp3
        02 Ghosts I.wav   04 Ghosts I.ogg  list_of_music.txt
       $ mkdir mp3music
       $ mp3fs music mp3music
       $ ls mp3music
        01 Ghosts I.mp3  03 Ghosts I.mp3  mp3file.mp3
        02 Ghosts I.mp3  04 Ghosts I.mp3
       $ cp mp3music/*.mp3 /media/mp3_player_that_doesnt_play_flac_or_ogg_files

</comment><comment><AUTHOR> New to me, but perhaps not everyone else...

</comment><comment><USER6> I build my own fs in college, it was pretty fun.</comment>


Conceptual Debt Is Worse Than Technical Debt - <AUTHOR> https://medium.com/@nicolaerusan/conceptual-debt-is-worse-than-technical-debt-5b65a910fd46 <comment><USER2> Picking the proper names for software constructs is also part of that category. I'm always impressed at how choosing a slightly wrong-one can have a huge impact down the line. Somehow the brain doesn't map the name exactly to the current context and gets things wrongs, prevents clear thinking.

A good example is the RAILS_ENV environment variable. It's a mechanism to select a running mode of rails applications. Now unlike most applications debug mode is the default. It's called "development" and the normal mode is called "production".

Because of these naming decisions developers always confuse the RAILS_ENV to be related to the deployment target. They add a "staging" running mode and they start bundling configuration secrets into the code. And invariably these secrets get leaked on github when they decide to make the repo public.

For a long time I felt something wasn't right and couldn't point the finger at it and it took conscious effort to disambiguate that. And that's just for a single variable. Mind your naming :)

<comment><USER3> >Picking the proper names for software constructs is also part of that category. I'm always impressed at how choosing a slightly wrong-one can have a huge impact down the line.

Similarly I'm often shocked at just how critical name disambiguation is. There's a shocking number of extremely similar concepts when writing code which, when given the same name ends up causing bugs.

A good example is 'file' which can be used to refer to a file handle, file name, file object of some other kind, a 'file' representing an aggregate of information on person, and often it ends up referring to directories, devices and links as well.

<comment><USER2> It's a good example. It also makes me think of "users" tables instead of "accounts".

<comment><USER4> Unless it's a financial application...

</comment></comment></comment></comment><comment><USER5> I think the term 'Conceptual Debt' is not helpful. The reason why 'Technical Debt' was coined was to help non technical shareholders understand that although software may work as designed to the user there may be unseen technical trade offs that have a real measurable negative impact in the long run.

What this article describes is 'just' bad product design, the application works as designed but the end users are confused by the product.

<comment><USER6> The distinction is not only helpful, but fundamental. You can have clean, beautiful code that implements poorly-named, ambiguous, or half-baked concepts -- that's conceptual debt. You can also have a well thought out product, broken down into simple concepts, that is implemented by inexperienced programmers as a mess of speghetti code -- that's technical debt.

Granted, the two often go hand in hand, but not always, and even when you have both, it's helpful to separate the two, as they require different remedies.

<comment><USER7> Isn't the concept of "Conceptual Debt" antithetical to the idea of MVPs,lean startups and the "ship fast, ship often" mantra dominating the tech culture nowadays?

<comment><USER8> No. Start-ups (and anybody else for that matter) just make certain compromises in order to ship fast(er). They still create conceptual debt, just as they do technical debt. The key is to go back and address both before they become uncorrectable (or, at least document/understand those compromises, so future developers don't waste time figuring it out).

<comment><USER9> Exactly. The important part of these phrases aren't Technical or Conceptual, it's the 'Debt' part.

</comment></comment></comment></comment></comment><comment><USER10> The article, which I liked, is very end user-oriented, but I think that the ability of other programmers to interact with your conceptual models is just as important. Other people have to work with your code, and their ability to develop new features will very much depend on how easily they can work with your conceptual models. Onboarding programming hires into a poorly organized conceptual model will be a mess, and disheartening to the new person.

Good conceptual models can be extended, interacted with, and built upon, and that which an end user may regard as a "feature," including features not yet thought of, flow naturally from the best models. So there are some knock-on benefits to the end user from good conceptual models under the hood, even if the end user doesn't see them or have an opinion about how intuitive they are.

<comment><USER11> When I first read the article's title, I thought basically the same thing: this is about the concepts the programmers embrace. But it turns out to be about the concepts the end users must embrace.

It's unclear to me how those two things are related. They _can_ be related, but it doesn't seem like they have to be. Not sure.

<comment><USER10> I think they don't have to be related. The article's example of tags and folders is a good illustration. "Tag" and "folder" models might have a clear enough implementation in the code; a programmer might wonder why they're both implemented but may have no trouble supporting both in principle. But the existence of both may be very confusing to the user.

The cost inflicted on the coders is not coders' conceptual debt, but users's conceptual debt - certainly costly to coders as they have to support multiple patterns, but I think there is a difference. I guess when I think of coders' conceptual debt, I'd think of something that may be abstracted away at the UX level such that the user doesn't see it, but inflicts pain on implementors due to counter-intuitive patterns.

</comment></comment></comment><comment><USER3> >Technical debt happens when you make mistakes like choosing the wrong database or programming language for the task at hand

Technical debt mostly means duplicated code, tightly coupled code and code that isn't programmed to fail fast. Those things can be impacted by the wrong choice of programming language or database but only indirectly.

Most of these things are pretty much unavoidable the first time you write code and you can only fix them once your code is surrounded with tests.

>The main issues in the case of technical debt are that the product is running slowly, not scaling well

Again, not really. The main issues are that the code gets buggier (owing to it being harder to reason about) and development gets slower.

<comment><USER12> That's how I think of technical debt too but I think it's worth considering database choice. When you start building an app, you'll choose postgres or mysql or another easy to get started with db. If you're ever fortunate enough to attract enough users to push beyond what those dbs can handle (or even require you to shard them), I think you've ended up in the relm of technical debt.

You took the easy path early on because it let you focus on acquiring customers and then you had to improve it later.

<comment><USER13> Assuming the code is well factored and the database access code isn't littered all over your code base. I'm not sure I would consider this technical debt.

Also, if Twitter and Facebook started out building their product to be used by millions of users, they would have gotten nowhere. They would have 0 users right now.

You can't really say Facebook took the easy path either. They went as far as creating a virtual machine and dialect based on PHP. And who knows what they had to do to get MySQL to scale like that.

</comment></comment></comment><comment><USER14> I think this article is completely stupid, and is "conceptual debt" in not understanding fully what technical debt actually is. This article describes BAD PRODUCT MANAGEMENT.

DEBT is an instrument. A good CTO/Developer will know when the codebase/product/platform is taking on technical debt. The same way you might take debt for a house, and pay back over time so you can LIVE in it. Shitty CTO's/Developers will take on tech debt without knowing it, and soon enough you're fucked. That's how people become homeless in the real world with real debt. (Well one way)

There is NEVER a time when you want to take on 'conceptual debt' AKA make crap product choices. That is just being stupid or short sighted. The only time to take on conceptual debt is if I am a development agency being paid by rich stupid people, and I want to make as much money as possible and not care about my reputation with them.

</comment><comment><USER15> We did a "team building" exercise once. The scenario was that our plane crashed 10 miles from a town in the Canadian winter. We had to prioritize 10 items from about 25 that we had on hand. Of course some groups decided to camp and wait for help, and others decided to set out on foot. People decided the usefulness of the items and made list. When it was all done, the answers were compared to those of a survival expert - who incidentally said we'd freeze if we tried to make the journey to town.

I made the point that the "correct" list of items was strongly dependent on which top level strategy was chosen, and that this was a reason for solid planning from the top. If your product is holding off on big decisions because the leaders can't make them, you'll be working toward multiple possible outcomes at the same time and burning a lot of extra effort.

</comment><comment><USER16> I've often heard the idea that "the way the application is coded shouldn't dictate its UI" which is true, but leads people to think that the application architecture should be divorced from the UI, and I don't think that's true either. You should first figure out the intended mental model of how the application works, and then from that should flow both the UI and the application architecture.

In my experience, apps that start code-first tend to end up a CRUD apps and require a lot of composition from the end-user; apps that start UI-first tend to generate a lot of exceptional use cases and workarounds. Both give the user a muddy mental model of how the application should work.

<comment><USER17> I used to be a heavy Flickr user and I remember clicking around one day and thinking, "I can visualize the sql calls being made to generate these pages". That didn't feel too great.

<comment><USER18> No idea what you're talking about. I can visualize the SQL calls being made to render this HN comment thread. So what?

<comment><USER19> I don't think this website uses SQL at all. :-)

[https://www.quora.com/What-is-the-Hacker-News-technology- sta...](https://www.quora.com/What-is-the-Hacker-News-technology-stack)

<comment><USER20> is there a reason or benefit to do that?

<comment><USER21> File system storage is much easier to reason about if you can't lean on a library, you can simply use the underlying OS. HN was built with a homegrown Lisp called Arc, and so can't rely on a vast community to provide a proper ORM.

Community support is why I write my personal projects with Ruby and not something like Arc. I don't want to have to reinvent everything just to get something basic done.

</comment></comment></comment></comment></comment></comment><comment><USER22> I think the term he's struggling toward is something like "user experience debt" [1] or "product design debt" [2], an area that has been discussed for years.

I think "conceptual debt" is a poor choice of phrase here, as one important kind of technical debt is the sort of software design debt where your domain model ends up being a poor fit for your domain, often because the domain concepts themselves shift. (For those interested, "Domain-Driven Design" is a great book relating to this [3].)

I also find the "worse than technical debt" headline irritating. It's the sort of, "the thing I specialize in is _way_ more important than the thing you specialize in" thinking that is poisonous in a team environment. Which one is actually worse depends a lot on your product and your business conditions.

[1] [https://medium.com/@vijayssundaram/user-experience- debt-c9bd...](https://medium.com/@vijayssundaram/user-experience- debt-c9bd265d521b#.ap1dujn8g)

[2] [http://andrewchen.co/product-design-debt-versus-technical- de...](http://andrewchen.co/product-design-debt-versus-technical-debt/)

[3] [http://www.amazon.com/Domain-Driven-Design-Tackling- Complexi...](http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity- Software/dp/0321125215)

<comment><AUTHOR> Thanks for the recommended reads, enjoyed them and they're hitting on really similar notions. Well cited comment :)

Conceptual debt is product design debt like you're suggesting. In particular, I think of it as a subset of product design debt that has to do with domain modeling as you suggest vs. having the write domain models but having poor user flows around those core concepts.

Unlike user flows, concepts are also reflected in the API & Object Models in your codebase so those may be trickier to change than the user flows that revolve around them.

<comment><AUTHOR> Also just ordered that book. Looks like a good read

</comment></comment></comment><comment><USER23> You have renamed "Design Debt," as outlined here back in 2004 by James Shore: [http://www.jamesshore.com/Articles/Business/Software%20Profi...](http://www.jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Design%20Debt.html)

Design Debt is not a new concept. It is a common cause of product failure. Taken from the link above:

"'Design debt' explains the problem. When a team is working under pressure, they take shortcuts that compromise design quality. It's like taking out a high-interest loan. The team gets a short-term boost in speed, but from that point forward, changes are more expensive: they're paying interest on the loan. The only way to stop paying interest is to pay back the loan's principle and fix the design shortcuts."

<comment><USER24> Except that your link explicitly states that "design debt" is also called "technical debt." This piece is trying to make a distinction between technical debt and something else.

<comment><USER25> One could argue wrongly so.

To me at least, what OP described as "conceptual debt" is really just design debt. Which all seemed like down to earth technical debt. I honestly see no reason to distinguish the three. Plus they typically stem from the same sources - that is, enterpreneurs and managers that want an MVP without actually grokking the V bit in the latter acronym, and managers who cut corners to slash short-term costs.

By contrast, technical debt is very different from, say, organizational debt. Which arises when your organization's staff grows faster than it's able to organize the workload around new hires.

<comment><USER23> Yes, precisely.

</comment></comment></comment></comment><comment><USER26> Honestly, all the conceptual debt I've encountered has been at the hands of bad product managers. Product managers who have no grasp on how users are using the system, don't talk to users, and just blindly create features for features-sake.

<comment><AUTHOR> Agree. Conceptual Debt is the domain of Product Managers, and they're the ones responsible for preventing it and fixing it.

<comment><USER27> This is absolutely wrong in practice, in my experience. Non trivial conceptual issues are very often raised when trying to implement things. Only then do you start to realize you're starting to code the same thing twice, or that you've got many unhandled behaviors, etc.

Bad conceptual design is due to poor communication between end-users,product owners, and coders.

The reason a product owner can't handle all conceptual issues in advance is because he speaks english, and not logic. His terms are poorly defined compared to the need of a mathematicaly correct definition of his problem space. Only when you start to code things do you realize that things are much more complicated ( or can be simplified).

<comment><USER16> _The reason a product owner can 't handle all conceptual issues in advance is because he speaks english, and not logic_

Is there a reason the product owner can't speak both english and logic? It seems like establishing mental models of how the application is working requires at least some level of logical thinking.

In the past I have worked on projects where the product owner wasn't thinking only in terms of output and not how the application achieved its goals. The result was an initial overly simplistic happy path design, followed by developers poking holes in it, followed by the product owner adding a series of exceptions to the design to try to handle the edge cases. Neither side felt ownership of the mental model, and it turned out to be a mess.

<comment><USER28> "Is there a reason the product owner can't speak both english and logic?"

Theoretically no, but it's a big ask for one person. In reply to this entire chain, I'd suggest that it's actually something for the technical lead and the Product Manager to work out in conjunction with each other. For any team past about 4 people, it's just going to be too much to expect someone to both be the technical lead _and_ be in contact with the users enough to be able to make those decisions. (A bit of crosstraining may be good, but trying to avoid that specialization is probably asking for trouble.)

If the PM and the lead don't respect each other enough to make that work, you've got a people problem. There's a lot of people-problem ways to muck this up, unfortunately. (Most obviously, I'd contend that making the PM be _above_ the tech lead is a very common failure case. If you can't trust anyone on the engineering team to have a roughly equal voice in the product design process... uhhh... that's a pretty big problem on its own!)

</comment></comment></comment></comment></comment><comment><USER29> I've seen products marginally succeed with major conceptual and technical debt. But in the long-term, it's always bad news.

It's more difficult to compete because you can't easily move forward without breaking a bunch of already existing features and it ends up costing the company lots of money because of the extra time needed to complete anything.

I think the worst case I never saw was an app that was built by overseas developers. The boss, who knew nothing about technology or software, just wanted something cheap and fast. When I came on board as a consultant, we had two parallel apps (the new one and the old one) and any new feature took 10X as long.

Customers slowly left to competing apps that could move much faster and the boss ended up letting all of the US-based developers go. She told me in my exit interview that she could hire 3 people in India for what she was paying me.

I suppose it was the best thing that happened to me because it pushed me to work on my startup full-time.

</comment><comment><USER30> The analogy with technical debt is poorly conceived. :) Technical debt (as with financial debt) should be a conscious trade-off; borrowing time now that will be paid back later. There's never any reason to choose a poorly modeled UI.

<comment><AUTHOR> That's a good point :)

</comment></comment><comment><USER31> tl;dr: "Conceptual debt" is what Ward Cunningham described as "technical debt". That thing _you_ call "technical debt" is just a combination of bad habits, haste and apathy.

<comment><USER32> "Shipped is better than perfect"

As much as it hurts my engineering sensibilities, 9 times out of 10, being hasty is better than not existing.

<comment><AUTHOR> Agree with the 'Shipped is better than perfect' and also the notion of isolating the dirty parts.

I've been adopting this rule of thumb that the first pass at a new product I can just dive in and treat it as a throwaway, since I probably don't understand the domain well enough to develop an ideal conceptual model anyways. The key here being to treat it as a throwaway and then return and do a rewrite from scratch once I have a better understanding of the problem.

<comment><USER10> I agree totally re your point of not understanding of the domain, it can be really hard to make good conceptual models until you've actually tried throwing some code at the walls.

I guess I'd rephrase your point about "one to treat as a throwaway" as saying that you should realistically expect to be moving back and forth between architecting the conceptual model and implementing it. I find it useful to first think about the conceptual model, then write some code for a while, then revisit the model and see what difficulties I've hit and/or what new good ideas I've thought of in the process, etc.

<comment><AUTHOR> Definitely what you're saying. Thanks for adding even more deeper context. Accepting that back and forth: code, learn, code process.

And to your point too about first thinking about the conceptual model, agree that you should spend at least a bit of time before doing anything else. Thinking through your modeling is something that doesn't take that much time and has such huge payoffs in terms of avoiding pitfalls. But often times it's just funner to start writing code so people do that.

It's always saddening to see programmers just dive in and start coding without planning / thinking about the problem first.

</comment></comment></comment></comment></comment><comment><USER33> This is why the API should ALWAYS at least have a first pass before any coding is done. Changing how things look and feel after the fact? Not an issue. Changing the underlying data structures? Holy shit, kill me now. Hell, if your API is solid (and you're using actual restful calls) then you should be able to completely decouple UI coding, business logic, and data management. Of course with the modern love of AGILE (see rapid prototyping) people wonder why so much rework is always needed because that's simply not the case.

<comment><USER34> This doesn't actually work unless the "first pass" on the API consists of using it to build actual programs, preferably multiple ones of wildly different genres. Otherwise, you end up with an API that is a beautifully designed ice crystal, perfect for the use case that the founder envisioned and generally useless & frustrating for real-world customers. That's exactly the type of conceptual debt that the article is talking about.

</comment></comment><comment><USER35> An interesting side issue here is that bad conceptual model gets the more entrenched the more tests you add. Fixing the flaw becomes almost impossible because it breaks all the tests.

Testing is often presented as a panacea but this is one of the cases where it hurts more than helps.

<comment><USER36> This is like saying the more developers you put on a project, the more entrenched you become...so developers are not a panacea.

If you need to write quality code, you will need to invest in writing tests. If you wrote the wrong code, yes, you will need to rewrite the tests. But that's a different problem.

<comment><USER35> > This is like saying the more developers you put on a project, the more > entrenched you become...so developers are not a panacea.

See Mythical Man-Month ([https://en.wikipedia.org/wiki/The_Mythical_Man- Month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month))

</comment></comment></comment><comment><USER37> I _want_ to be convinced, but I'm not yet. TFA would be more persuasive if it included more than a single "software has two concepts that are effectively identical" example. I'm thinking of screwed-up shit I've seen in the past, and I don't know whether it fits into this or not.

For instance, one company that employed me spent extra person-years creating new service plans because a single internal index in a vendor-supplied product had _once_ been communicated to accounting, and thereafter they _had_ to see it everywhere, and it _had_ to take different values everywhere. Actually I think the accounting department would have had to lay someone off for inactivity if they couldn't spend so much time tracking this one stupid DB key through nineteen different reports. Was that "conceptual debt"? [EDIT: to be clear, "creating new service plans" was a good thing, that allowed us to acquire more customers. If the interface to G/L hadn't been fucked up in this fashion, we could have done that good thing _much_ more quickly.]

</comment><comment><USER38> When I first read "conceptual debt" I thought it would mean poor architectural decisions as it relates to building software. Of course that's not what he meant. What he really means is what I would call "UX debt" if I were crafting a name for it.

I don't think it's helpful to create a new term to describe something that could be easily encapsulated by using a term that most everyone already knows, is industry standard, and is implicitly obvious to anyone versed in the practice of building software products. Right now "bad UX" would be the same as "UX debt". That terms makes sense to me because it codifies a real concept that I've absolutely held in my mind.

With all due respect to the author, and I applaud his effort to try to improve communication tools, I believe this name has "conceptual debt" :)

<comment><USER39> "UX debt" feels rather broad - a whole range of tactical issues like color scheme consistency, button naming, inline vs modal editing, etc could be lumped in. I rather like the term "conceptual debt" \- conceptual issues at the UX also usually have deep effects on the data model and deeper parts of software architecture. "There's something wrong with the UX of your app", "there's something wrong with the technology of your app", and "there's something wrong with the concept of your app" all register distinct meanings for me, even if there is significant overlap.

</comment></comment><comment><USER40> This applies to much more than product design.

I see many Adwords accounts that are structured based on a best practices boiler plate format...but fail to consider how the structure will interact with decision making in the future, forcing poor budget allocation or worse, making proper optimization unfeasible.

Having a very clear vision from the outset for how you will need to adjust and optimize in the future and building an account structure in format that aligns with those processes is often the difference between a very successful account and a mediocre account that only shows minor incremental growth...

Avinash Kaushik wrote once, "spent 95% of the time defining the problem and 5% solving it."

</comment><comment><USER41> > Conceptual debt is often the difference between a product succeeding or > failing.

Is it, though? I have seen plenty of products that succeed with plenty of the type of debt the article speaks of.

</comment><comment><USER42> "We're paying for bad design decisions."

"We're paying conceptual debt."

Which phrase sounds more clear to you? Also, which phrase exists for the sole reason of communicating nothing while making you sound more intelligent? I truly hope "conceptual debt" doesn't become a new buzz word.

</comment><comment><USER43> I had a mild climactic sensation when I read the title of this post. I said the same exact thing a while back to my colleagues regarding some big conceptual errors that were made on a project a year ago and how I believe it will cost us a lot more than a years worth of work to pay this debt.

</comment><comment><USER44> This just sounds like a description/discovery of UX/service design. BDUF is also a huge problem there, hence Lean UX

</comment><comment><USER45> Conceptual Debt is a terrible new name for something that everyone already understands: Bad User Experience/Interface.</comment>


From a startup in Vietnam: Asking for feedback on our prouct - <AUTHOR> https://antbuddy.com/ <comment><AUTHOR> Hi guys,

We're a startup in Vietnam. We've developed a unified communication tool for small business. You can see us as a combination of Slack and Skype, and we're free. All essential communication needs like chat, call, conference call, video call (1:1), file shared, cloud storage, and search are free. We'd like to ask you guys to try it out and give us feedback to improve the tool further. Thank you very much.

An.

</comment><comment><USER2> First impression: it looks very much like Slack and I don't see where it explains it is a combination of Slack and Skype? There's no mention of conference call and video call.

<comment><AUTHOR> Hi, my apologies. The landing page is being updated to reflect all the changes. But AntBuddy is a working tool with all the features I listed. Thank you for your time. We'll focus more on the landing page.

</comment></comment><comment><USER3> The video has no audio. Leaving me to figure out what is going on. If you are asking me to invest my time watching don't ask me to do extra work.

<comment><AUTHOR> Hi, my apologies. The landing page is being updated. We've focused on the features of product and somehow neglected how we present it to world. We're still on the learning curve. Thank you for your time. We're fixing these problems at once.

<comment><USER3> My comment was meant to be helpful, reading it again seems a little harsh in tone. Good luck</comment></comment></comment>


Oracle VP: Data would be safer if most OSS distributed databases didn't exist - <AUTHOR> https://twitter.com/matthewokeefe1/status/1226945620801413120 <comment><USER2> When I read content like this, I can't help but be reminded of Bryan Cantrill's talk at USENIX entitled "Fork Yeah! The Rise and Development of illumos" from 2011 [1].

Some personal favorites:

> You actually don't need to be open-minded about Oracle. You are wasting the > openness of your mind.

> What you think of Oracle, is even truer than you think it is. There has been > no entity in human history with less complexity or nuance to it than Oracle.

> You need to think of Larry Ellison the way you think of a lawnmower. You > don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you > stick your hand in there and it'll chop it off, the end. You don't think > "oh, the lawnmower hates me". The lawnmower doesn't give a shit about you, > the lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't > fall into that trap about Oracle. [...] The lawnmower can't have empathy.

[1] [https://youtu.be/-zRN7XLCRhc?t=2040](https://youtu.be/-zRN7XLCRhc?t=2040)

<comment><USER3> I think this is true for all corporations. In my opinion, all corporations are driven by the bottom line, not by emotions.

<comment><USER4> It's not. Tesla is ran by a pretty awesome guy. So are many other companies. Some visions happen to be compatible with ethics. When one's brand is backed by ethics, investors know what they are getting into. A lot of mountaineering companies and outback companies are actually like that.

<comment><USER5> Umm Tesla has plenty of "soulless corporation" going on - again, quit anthropomorphizing minmax optimization engines.

[https://www.theguardian.com/technology/2018/jun/13/tesla- wor...](https://www.theguardian.com/technology/2018/jun/13/tesla-workers-pay- price-elon-musk-failed-promises)

[https://www.revealnews.org/blog/a-users-guide-to-teslas- work...](https://www.revealnews.org/blog/a-users-guide-to-teslas-worker- safety-problems/)

[https://www.businessinsider.com/tesla-factory-workers- detail...](https://www.businessinsider.com/tesla-factory-workers-detail- grueling-conditions-fremont-2017-5)

</comment></comment></comment></comment><comment><USER6> You really can trust Oracle to be the most disgusting version of a corporation given any set of circumstances. It's literally amazing, they're like clockwork.

<comment><USER7> I can easily amuse myself by recalling the Star Trek episode where all the evil twins had goatees, and wondering where Larry's good twin is now.

</comment></comment><comment><USER8> Most economy scale transactional stuff is on things not a lot of people have experience with these days like TPF, or CICS and VSAM and to some extent DB2. Oracle is more of a "mid range" DB for financial workloads and wouldn't be comparatively hard to replace with, say, postgres, as many companies have.

<comment><USER9> Could you shed some light on the sector and infrastructure where TPF, CICS and VASM are used? I've never heard of it and had to google it all[1]. What exactly do you mean by "economy scale transactional stuff"? Is something like central bank clearing house?

[1] [https://en.wikipedia.org/wiki/Transaction_Processing_Facilit...](https://en.wikipedia.org/wiki/Transaction_Processing_Facility) [https://en.wikipedia.org/wiki/Virtual_Storage_Access_Method](https://en.wikipedia.org/wiki/Virtual_Storage_Access_Method) [https://en.wikipedia.org/wiki/CICS](https://en.wikipedia.org/wiki/CICS)

<comment><USER8> I might be able to but you are already on your way, branch off the references links there and look at open source (in the intelligence sense) of places like resumes and linkedin to see who is using what. Some permutation is used at the nucleus of card networks like visa, ACH, most public stock exchanges, and a lot of other financial instrument markets, as well as the systems of record for some of the largest banks and governments.

</comment></comment></comment><comment><USER10> In 2017 big blue had decided enough is enough. Let's move to those hip new technologies like, php and MySQl. Let's do angular too!

It was a small simple application. It took no longer than a week to migrate to mysql. Unfortunately, we had a long term contract with Oracle. It didn't matter that we weren't using their db anymore, we still had 10 more years to go.

The strength of the Oracles and IBMs of the world is not in technology. It's in sales.

</comment><comment><USER11> The FOSS community would be a lot safer if Oracle didn't exist.

</comment><comment><USER12> Sometimes I wonder about the type of people who willingly choose to work at Oracle. Unsurprisingly, this is Oracle's best.

I wonder what Oracle's doing to get this sort of loyalty; not many employees are willing to turn their personal twitter accounts into ad space.

<comment><USER13> I didn't want to rush to judgement so I took a look at his other tweets. I think this person may have never actually been in situations where a decision had to be made between different db options. Such people come into technology in the world of big corps and drink the kool aid; different technologies are more of a tribal or a popularity contest rather than a genuine technical assessment. Never take these people seriously.

</comment></comment><comment><USER14> Wake me up when they are disavowing/discontinuing "owning" mysql.

</comment><comment><USER15> And it was removed. Wayback caught it: [https://web.archive.org/web/20200216050450/https://twitter.c...](https://web.archive.org/web/20200216050450/https://twitter.com/matthewokeefe1/status/1226945620801413120)

</comment><comment><USER16> They mention distributed databases, not traditional RDBMS.

Elastic databases have been at the source of countless leaks, this tweet doesn't seem out of place.

<comment><USER17> Elastic databases have been the source of leaks because of incompetency of the people deploying it, not because of its FOSS license.

</comment></comment><comment><USER18> There are good OSS databases like Postres and MariaDB, and there's also crap like Mongo.

Even though there are OSS databases better than Oracle, it could be true that data on OSS databases might be safer on Oracle on average.

Also, even though Oracle engages in horrible unethical business practices, I hear that their database product isn't bad.

<comment><USER19> How many more businesses, if financially strained by Oracle licensing fees, would be tempted to sell data about their users to make up the difference?

<comment><USER13> I have to sell user data because my dB licensing fees are too high.... is one hell of a take. Has that happened like ever?

<comment><USER19> It's a big world. A lot of businesses are only marginally viable already, and a lot of business owners are only marginally ethical. Many already sell user data. I think it likely that squeezing such businesses even harder from the top might have negative consequences for the people at the bottom.

</comment></comment></comment></comment><comment><USER20> That Oracle VP should explain why their software puts a short limit on the length of the password (in PeopleSoft).

Whenever I see that someone limits the length of the password I know that problems are nearby.

This software is disheartening.

</comment><comment><USER21> You would have less leaks with Oracle because you would not be able to afford the database in the first place. Can't leak anything if it's not stored

</comment><comment><USER7> It's easier to secure things when there are less of them to keep track of. They're not wrong. Or not even wrong? One of those.

</comment><comment><USER22> Yeah, sure. Keep dreaming Oracle, keep dreaming. World would be much better place without such greedy and nasty companies.

</comment><comment><USER23> Scott/tiger

<comment><USER24> dual

</comment></comment><comment><USER25> To be fair, data _would_ be safer if MongoDB didn't exist. Then again maybe it's better to have all the people working on it in one place so they can be avoided all together.</comment>


Why poor stay poor - <AUTHOR> http://www.slate.com/articles/life/family/2014/12/linda_tirado_on_the_realities_of_living_in_bootstrap_america_daily_annoyances.html?wpsrc=fol_fb <comment><USER2> This is why click-bait journalism is terrible.

You have a headline that makes it seem like an interesting answer will be revealed for tough conflict, only to have a rambling series of anecdotes that doesn't address the headline and reads like an advertisement for a book.</comment>


Lisp Machine Hacking (2018) - <AUTHOR> http://victor.se/bjorn/lispm.php <comment><USER2> I would love to get my hands on an old Lisp machine, just to play with it. While there's obviously nothing pragmatic about using one of them nowadays, I think they're an incredibly interesting footnote in computing history, and I always like to think about the "what if?" universe where Lisp-centric architectures were the norm.

<comment><USER3> I work at a company that's been using Lisp since the 80s, and we have an old Lisp machine serving as a coffee table/conversation piece in our entry area :)

<comment><USER2> If you're in the NYC area I'd like to see that; for that matter, I'd like to see any company that's been using Lisp since the 80's...clearly their engineers have good taste.

<comment><USER4> Alas, we're in Austin ([https://en.wikipedia.org/wiki/Cyc](https://en.wikipedia.org/wiki/Cyc)). I just checked and the exact machine is a Symbolics 3630.

<comment><USER5> whoa! Cyc is still around? As in Lenat's ontology of everything project?

<comment><USER6> It managed to cling to life by converting into a counterterrorism project and allowing itself to be funded by the Department of Homeland Security.

<comment><USER4> I think it's been over a decade since we've done work for the government, but yeah, one does find a disproportionate amount of terrorism-related facts popping up when combing the knowledge base, sometimes yielding comedic results when Cyc is asked very open-ended questions.

<comment><USER7> Does Cyc still claim that the reason for going to the dentist was to have DazzlinglyWhiteTeeth?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> A while back I picked up a copy of "LISP Lore: A Guide to Programming the LISP Machine" at Goodwill, for $1

The Lisp dialect is dated, and the code isn't runnable on a modern machine, but it's still interesting to see the Lisp idioms and techniques used, the API design, etc.

[1] [https://www.amazon.com/LISP-Lore-Guide-Programming- Machine-e...](https://www.amazon.com/LISP-Lore-Guide-Programming-Machine- ebook/dp/B00FBHUHQ4/)

<comment><USER9> After I finally bought a copy (at a pretty expensive price), someone uploaded a version to the Internet Archive:

[https://archive.org/details/lisploreguidetop00brom](https://archive.org/details/lisploreguidetop00brom)

</comment></comment><comment><USER10> Maybe one could build a retro Lisp machine keyboard using the same modular parts as: [https://old.reddit.com/r/MechanicalKeyboards/](https://old.reddit.com/r/MechanicalKeyboards/)

<comment><USER11> I'd pay good money for one. If anyone does this, please let me know.

<comment><USER10> I think this is totally possible to do as DIY, as seen in that subreddit. :) Anyway, probably someone will do it first, and post a photo series of the steps, and then more who want a new and sustainable Lisp power-user keyboard will be inspired to do it.

</comment></comment></comment><comment><USER7> I have a friend in Mountain View with a bunch of symbolics machines in his garage. He's in the process of moving house so wants to get rid of them soon. Anybody who wants to give one a good home and can pick one up from Mountain View let me know and I can put you in touch.

<comment><USER12> I have been actively repairing and reverse engineering a number of lisp machines from Symbolics- including original L and G machines (36xx).

I have working disk emulation, 'breath of life' for bringing up new system disks, and a number of folks can probably attest I'm the best home to preserve these long term.

I can arrange pickup.

I also will keep the systems together, safe from keyboard collectors.

Please, get me in touch with your friend.

My love of these systems and desire to properly preserve them runs deep: email@example.com

<comment><USER7> I forwarded this comment to Phil.</comment></comment></comment>


Bernie Sanders Aims New Tax Hike at Executive Retirement Plans - <AUTHOR> https://www.wsj.com/articles/bernie-sanders-aims-new-tax-hike-at-executive-retirement-plans-11582815616 <comment><USER2> I'm pretty privileged and more than happy to pay a reasonable tax on my fortune if people richer than me who can afford to assemble legal tax shelters can be wrangled in to pay their share too. Also, tax churches.

If we could incentivize startup structures that are less focused on pump and dump #growthhax and more on creation of organizations that produce value for the communities they are in and the people who trade their lives and labor for a crumbling fig leaf of security and happiness. That shit would be hot.

VC money is crack money. The squandered wealth propped up by rich opportunists on the backs of creative efforts of hard working people hedged so said rich people can fail upwards while worker lives are ruined for a taste of a Zuckerberg dream is gross. Without dinging the frequent big winners in this space via taxes there isn't really a mechanism to encourage self regulation.

<comment><USER3> That churches thing - I find they have other benefits too.

Is there a few clicks create a church have all the legal and what-have-you filed and such like stripe does with del corps?

Might be time to setup one of these things.

<comment><USER2> It does appear that a lot of people believe religiously that they shouldn't pay taxes. We should all start churches. Maybe get a lawyer or three involved and make enough churches flagrantly abusing the law that the supreme court has to hear a case. The Church of Satan kind of does stuff like that.

They do have other benefits but they very state to state. Like that guy that legalized his ayahuasca church in Kentucky[0] because they have a law that says you can do whatever drugs you want if it's a religious ceremony. It's stupid that you need a church for that, but also pretty rad that he can do it there. It appears to be helping a lot of people.

It appears that there are services for filing the needed documents. StartChurch.com pops up with a quick google. It looks nice.

[0] [https://www.youtube.com/watch?v=-88xpl-5ro0](https://www.youtube.com/watch?v=-88xpl-5ro0)

<comment><USER3> That startchurch looks like they do do it! thanks for that.

I have been kicking the idea around of starting a few 'churches' just have an open 'third place' \- I don't mind whatever religions stuff people choose to follow - I'd perhaps want to open a 'coag - church of any gods' and let people choose their own flavors.

To me a 'church space' should/could be all inclusive - even athiest / satanic whatever - life's a journey, things change, no judge all that.. a dojo is just a building where people train.

I like the tax break options, and let sub-groups be pro-active in whatever their chosen things are.

I read a story this week saying some atheist groups are actively trying to stop some religious texts in all government building in a certain state? I found another atheist group doing stuff for homeless that does not push religions.. I would encourage those kinds of things I think.

you mention the ayahuasca - I knew some native Indian folks some time ago that got peyote twice a year legally for their ceremonies, and have read Oregon has taken something like that to their state supreme court?

There are sometimes counseling services offered by these places where the people are not licensed/dr degreed right? So affordable someone to talk to could be offered.

It is interesting the exemptions that are made in the name of the invisible man in the sky as george carlin put it.

I found that our city (maybe state?) has exemptions for codes with churches - so you can't build a tiny home community with r10 zoning here, but if you have a church there are not restrictions on buildings.

As to where I don't particularly care for some of the extra tall buildings in the area, perhaps it's time to take advantage of their exemptions rather than just be miffed that they are getting them.

/randomthoughts

<comment><AUTHOR> I was part of such a church. It's not active anymore.

[http://www.churchofvirus.org/](http://www.churchofvirus.org/)

It was good. Then it was bad. It got worse. Then it died a sad death.

I am pretty sure some of it's members are probably right here on HN. Different time and another lifetime for me.

<comment><USER3> I'd love to hear a synopsis of that situation! I appreciate this bit as well. Makes me think something like this could quickly outgrow itself, and rather than trying to keep so many voices under one growing roof, perhaps it may be best to split in half and split again to keep things manageable and cordial and not have things get worse than bad. But still do the things it was set out to do - provide an open third place for people who may not have such and take advantage of some discounts along the way.

<comment><AUTHOR> It is difficult to create a synopsis for this because it's a lot of things..little little things that mushroomed and eventually caused the group to implode. There are other things that happened and I can't talk about it.

But I will say this...the biggest cleft occurred after 9/11\. It was a very bad time for the group to be cohesive. Looking back, it's rather remarkable. I actually want to write about it some day because it was a pressurized emotional highly volatile environment where seemingly like minded people couldn't stand each other's POV anymore.

The group was around for a decade plus after that..but weaker. The 'virus' came from how thoughts are like virii and can infect people. And every member of the congregation can be a vector for rational thought. We'd spend hours discussing (remember BBS and Dalnet/IRC?) how religion was a virus and only rational atheistic thought could vaccinate people against the virus of god. Darwin was our prophet. Evolution explained life. We celebrated his birthday. Man..those were some good times.

Of course, even then no one got along..but we were all still arguing with 'one of us'. But 911 changed _everything_.

That's when it dawned upon many of us..the most dangerous virus is not religion..but politics. What bound us was not as strong as what divides us.

It was just sad after that. Slow agonizing ugly death of something that could have been beautiful.

I was very young then..in the two plus decades since, I have changed too. I stopped calling myself atheist and became agnostic for a while. Then I called myself ignostic and until recently didn't care. As I get older, I feel I am ready to explore and am willing to test if faith is more nuanced than 'organised religion'.

I don't know. I guess we are always looking for answers. And when we are not, we invent questions to look for answers.

To your point, I disagree..congregations need to be large. We were trying to replicate how a virus works by spreading rational thoughts memes and the more people we infected with our thought memes, the more successful we were going to be in promoting the virian ideal and virtue of pure rational thought.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> What's fascinating about Bernie is how familiar he is.

A 1960s radical who went to a top level university (UofC), has never belonged to a union, has worked in government or non profit sector all his life, etc.

Never worked for consulting or finance or academia.

There sorts of folks used to be much more common in politics. Now they're mostly retired.

It's not bad per se. But not really new. In fact, very very old.

I guess Bernie is the last roar of the 1960s generation.

Very telling that his generation is rejecting him in the polls. 1960s radicals were always divisive an unpopular in mainstream America.

The left hasn't done a very good job figuring out what it's next step should be, so taking a step back might be a good idea.

<comment><USER5> Really confused by your comment to be honest. Maybe it's an age gap thing? because Bernie is a deeply unfamiliar political animal to people who are less than 40.

Also the left knows exactly what it's need step should be. There's obvious changes to be made in the areas of healthcare, wealth inequality, and environment.

In what sense has "the left" not got a clear next step?

<comment><USER6> Maybe the commenter failed to distinguish between "left" and "liberal", resulting in a confusion. Right now it's the liberals who doesn't have a clear next step, failing to acknowledge that they are part of the problem for the US's staggering wealth inequality (which by the way, is the fundamental reason why Trump won), and now just trying to present a more "milder" version of Bernie's policies to pander to voters.

<comment><USER4> I was referring to the Democratic Party, which is the more left leaning of the two main American political parties. And additional any left of center activists affiliated with it.

Yes, one can refer to liberalism in an economic and philosophical sense which is very different.

Yet, few Republicans, including very libertarian leaning ones, would ever identify as liberal.

Nobody would call Barry Goldwater a liberal, even though he very much fit the definition.

<comment><USER7> > Nobody would call Barry Goldwater a liberal, even though he very much fit > the definition.

Only in the latter years of his career. [1]

1\. [https://en.wikipedia.org/wiki/Barry_Goldwater](https://en.wikipedia.org/wiki/Barry_Goldwater)

<comment><USER4> He never identified as a liberal, even in later years. He consistently called himself conservative. He accused the Republican Party of becoming liberal.

</comment></comment></comment></comment></comment></comment><comment><USER8> Looks like this would tax options at vest rather than exercise, essentially ending employee equity comp in startups.

Interesting how he wants the workers to own the means of production but also is trying his damndest to disincentivize it.

<comment><USER9> It's great that a small group of people are getting rich with stocks at tech companies, but maybe another socioeconomic group needs some help for a change.

<comment><USER8> It does not therefore follow that this rule is the key to making that happen.

<comment><USER9> Which rule? Owning the means of production (via employee stock ownership programs)? That's not a part of Bernie's campaign at all.

<comment><USER8> The rule this whole thread is about...

If he is correct in claiming that one group is being left behind, passing legislation designed to tie the hands behind the back of another group is not going to help the poorer group. His entire worldview revolves around the flawed misconception that the economy is zero-sum. That of course is a bunch of nonsense. Peter the software developer getting 0.25% equity stake in a startup does not hurt or hinder Joseph the line cook, and preventing Peter from getting that stake will not make Joseph better off.

</comment></comment></comment></comment></comment><comment><USER10> Is there any indication this would apply to all ISO/NSOs? Can't read the WSJ article (no subscription), but articles referencing it seem to be saying that it's targeted at highly-paid executives. Obviously this would be disastrous if it applied to all stock options. Just trying to get the facts straight before getting too riled up.

<comment><USER11> as a middle class tech worker i like bernie but he's going to fuck us over the most.

<comment><USER12> Maybe depends to which middle class you're comparing yourself to, the Bay Area, or the rest of the US.

</comment></comment></comment><comment><USER13> What's fascinating about Bernie's campaign is the almost identical stance he has with the Bolsheviks, that Google defines [1] as "...Russian Social Democratic Party".

So Bernie's P.R. consultants did the brilliant job of retaining _most_ of the Bolshevik diktat, and switching "Social Democratic" to "Democratic Socialist", in an apparent attempt at sanitizing brand socialism.

[1]: [https://www.google.com/search?q=Bolshevik](https://www.google.com/search?q=Bolshevik)</comment>


Reminder: HNKansai Meetup Tomorrow - <AUTHOR> http://www.hnkansai.org

<comment><USER2> I see you're trying to do some fancy CSS thing on the site. Unfortunately this means all the text is mangled into one big mess; completely unreadable. Might want to fix that.

Edit: Should add I'm using Chrome.

<comment><AUTHOR> That bug has been happening with older versions of Chrome. I know that's not an excuse, but you probably want to look into updating if that's what's happening.

<comment><USER2> I'm running a fully updated Google Chrome, Version 23.0.1271.91, out of the Arch AUR. [0]

I just checked against the current DEB download from google.com/chrome: 23.0.1271.91-r167501 [1]

Unless you mean beta or dev channels, this is the newest Chrome there is.

[0] <https://aur.archlinux.org/packages/google-chrome/>

[1] [https://dl.google.com/linux/direct/google-chrome- stable_curr...](https://dl.google.com/linux/direct/google-chrome- stable_current_amd64.deb)</comment></comment></comment>


Superfreakonomics: Superplug for Intellectual Ventures - <AUTHOR> http://rusty.ozlabs.org/?p=110

<comment><USER2> The one at the back of Superfreakonomics is weird. I thought that suddenly I was reading a different book. It honestly doesn't feel like the same authors.

Could it be a kind of ad? Can you approach a powerful publisher and _buy_ yourself a chapter in a book that is likely to be a best seller?

<comment><USER3> Did anyone else find all of Superfreakonomics to be a big let-down after Freakonomics?

</comment></comment><comment><USER4> They have succeeded in securing "superplugs" before; see <http://news.ycombinator.com/item?id=181392>

</comment><comment><USER5> The day is not far that Patent Troll Inc.s and their brethren will be thrown under the democracy bus. It is a matter of when, not if.

And it won't need a revolution, just enough in-fighting, a bit more alienation of the masses; which will be reaching critical mass soon enough given the number of entrepreneurs and small businesses paying licensing fees a.k.a. "Troll Tax" to these IP warehouses (whorehouses?).

I eagerly wait for the day this blows up in IV and friend's faces.</comment>


How Docker containers are different from system processes? - <AUTHOR> https://kjanshair.github.io/2017/07/04/Docker-Containers-vs-System-Processes/ <comment><USER2> I applaud the elaboration of containers as isolated processes, however, I abhor the anthropromorphization of the Kernel/CPU in this article as it tends to distract from what the machine is actually doing, and makes a value judgement with regards to how container technology does it's thing relative to how things just work.

Computers compute. The computer doesn't care whether a process is happening in a container or just as a system process. The CPU still has to context switch, it still has to flush and reinitialize memory, and it still incurs all of the same complexity that comes from being a multi-user OS when using containers vs. not using containers. If nothing else, there is actually MORE computation required with containers due to not being able to use more streamlined IPC mechanisms between containerized processes which would be usable in a non- containerized implementation.

Containers fulfill a HUMAN use case. "I want to scale a bunch of copies of software environment blah on hardware Y." The computer continues to do what it is told without a care in the world.

<comment><AUTHOR> I completely agree with you on this. This is a nice article which helps you picturize what a docker container is when your mind has already wrapped around what a system process is.

</comment></comment><comment><USER3> i agree with author and his article. The cgrougs is in effect now instead of the 'nice' value. Docker changes the game coz containers can run in pods or swarms across machines.</comment>


AMQP and Node.js - <AUTHOR> http://blog.bakker.pw/amqp-and-nodejs

<comment><USER2> amqp.node has a callback-based API if you don't want to use the promise-based API. But this guy reimplemented it, apparently because he doesn't like promises ("This library solves Issues 1 and 2 if you can put up with promises, but it still didn't solve Issue 3").

He must really hate promises.

<comment><AUTHOR> I didn't reimplement because of promises. Neither amqp.node nor node-amqp provided the direct access that I wanted.

The promise vs callback is a minor point as they are both equivalent with promises having a slightly higher overhead. But yes, I do hate promises.</comment></comment>