Infinitown – A WebGL Experiment - <AUTHOR> http://demos.littleworkshop.fr/infinitown <comment><USER3> Here is a another infinite city written in a WebGL shader. [https://www.shadertoy.com/view/XsBSRG](https://www.shadertoy.com/view/XsBSRG)

All the calculations are done on a per-pixel basis, there are no polygons or other objects created. The city is a 3d scalar field with effectively an isosurface plotted.

The city is made infinite with a simple modulo operation in X-Y on the field.

Interesting to note in this technique there is no additional computational load associated with more visible objects, and there can be as many objects as pixels.

<comment><USER4> That's pretty impressive, but it didn't work in FF (Developer 57.0b1 64-bit) for me, had to change to chrome and then it seemed to be getting 8fps (at least that's what the readout on that page was).

The Infinitown posted here was (pretty much) buttery smooth though, and relatively fast loading time (especially the second time with cache), and I bet the codebase is a lot easier on the eyes, though it's likely nowhere near as efficient as writing it all in the shader obviously.

Is the world just waiting for a no-dependency cross browser MMO/shooter/whatever 3D game to take the world by storm? Why worry about Steam when people can just go to a website, if the experience is good enough and the game is simple enough? I must not know enough about the industry/how hard it is to make a good game + how hard it is to make a truly good browser-only game.

<comment><USER5> While there might be something, modern games take a massive amount of data, and for a website, you'd have to load that before playing it. Plus it is difficult to monetize. Demos are fun and easy, full games take a lot of work. There are actually some cool web games already out there, but being in the browser isn't particularly interesting, in the end.

Infinitown is just a set of objects repeated in different orientations/combinations. The shader-city is awesome though. Very clever :)

<comment><USER4> If you're OK with handling a whole bucket of naivete, I'm going to really heap it on:

\- the game monetization problem's always around (and always going to be around) -- is there a reason one wouldn't pay for a game in their browser but would pay for one on steam?

\- Some of the greatest games of all time made do with so much less -- Isn't the resource problem just a matter of effort/ingenuity? Also isn't that problem bound to go away as time goes on? (though of course the "modern game" target will also move)

\- I must not understand enough of why/how the demos are so different. Isn't shader city doing the exact same thing but insted drawing the visible pixels in space (and from a different viewpoint) rather than rendering the higher level polygons? I thought the key innovation/hard bit was the fact that it was _inside_ a single shader.

<comment><USER5> Naivete is awesome when trying to not be it ;)

What does playing in the browser get you when you need to download 100MB+? You use the browser to get access to the standard features and DOM, if you ditch all that, add in a huge upfront download cost, then you might as well just install. There are plenty of cross-platform ways to do it these days. Additionally, browser games have an air (fair or not) about them of cheapness.

Then again, I'd be really happy if someone proved me wrong, and significant webgames became a thing. And it is a great exercise to analyze why webgames are bigger.

The infinite city is "just" tying a location to a randomly chosen and oriented set of objects. All the rest is standard scene graph rendering pipeline. The city shader does that for each "pixel" in the scene, and takes much less data to get a far cooler effect. Imagine coming up with an algorithm that picks a random lego object (a car, a police station, a boulder, etc) for each inch on your floor. That's infinicity. Now imagine picking a single lego piece based on your location and direction you are looking, and having that always match up even if you move, and when doing so, the resultant "legoscape" is a cool city. That's the city shader.

Sorta.

<comment><USER6> Being browser-based, you wouldn't be waiting to download 100MB+ if it's correctly designed

You'd download a 1-2mb core script bundle that then dynamically lazy-loads resources as required. For example, if Hearthstone were converted to a browser game, you would initially only load the base client, all the metadata and media (e.g. hero SFX, card data, effects, images) would be loaded on the fly as they are required, or pre-loaded at determined points (e.g. load all the data for both players' decks when beginning a match)

</comment></comment></comment></comment></comment></comment><comment><USER7> Little Workshop has done neat stuff, none of it rocket science, but all of it very polished. My favorite is [http://www.playkeepout.com/](http://www.playkeepout.com/)

Sadly they never seem to open source anything? It'd be nice to see how such polished stuff is organized

<comment><USER8> Thanks, Keep Out is also my favorite project.

Our first web game, [http://browserquest.mozilla.org](http://browserquest.mozilla.org), was actually open source: [https://github.com/mozilla/Browserquest](https://github.com/mozilla/Browserquest)

<comment><USER9> I'm evaluating some WebVR options right now and wondering what you think is state of the art. Are things like a-frame and react-vr a step forward or a crutch? Is Unity viable for web-first apps?

</comment></comment></comment><comment><USER10> This is so cool! I'm always blown away by your projects Little Workshop. I recently finished building my first ray-tracer ([https://github.com/diegomacario/Super- Sunshine](https://github.com/diegomacario/Super-Sunshine)). I felt proud of the images and animations I generated with it until I clicked this link - <USER2> I just feel like a caveman :p.

<comment><USER11> Have a look into implementing a glazed shader, it has some super nice results; it can give some surprisingly nice results for a very simple shading model [https://imgur.com/a/TcliH](https://imgur.com/a/TcliH) .

There are more details on: [http://www.cs.cornell.edu/courses/cs4620/2017sp/](http://www.cs.cornell.edu/courses/cs4620/2017sp/)

<comment><USER10> That bunny is stunning! Thank you for the link, it looks like a great resource. Refraction, here I come!

</comment></comment></comment><comment><USER12> That's pretty cool. Is there any way to rotate the camera? Also just saw a car and a truck crash into each other, but they both just drove off - next step maybe proper vehicle interactions and emergency services? :)

<comment><USER13> I was pleasantly surprised to see vehicles stopping for each other!

<comment><USER14> But they stop on the zebra crossings! No regard for pedestrians ;-)

</comment></comment></comment><comment><USER15> Runs absolutely flawlessly on an iPhone 7. I'm not a game designer so no idea if that's to be expected but to a casual it looks impressive running in a mobile browser.

<comment><USER16> Yeah I was really surprised how beautiful it is on my phone. Meanwhile my old i7 laptop barely gets 15fps...

<comment><USER17> Same for me on Chrome on Linux. I'm surprised I got anything on Linux since I didn't think Chrome devs bothered with webgl support on Linux.

Edit: Oh, this did the trick: [https://askubuntu.com/questions/299345/how-to- enable-webgl-i...](https://askubuntu.com/questions/299345/how-to-enable-webgl- in-chrome-on-ubuntu)

</comment></comment></comment><comment><USER18> Apparently, they are using three.js

The examples for this lib are also pretty cool:

[https://threejs.org/examples/](https://threejs.org/examples/)

<comment><USER19> I love making little demos with Three.js. It's amazing what a web browser can do these days.

The prettiest so far is [https://fenwick.pizza/rentaduck](https://fenwick.pizza/rentaduck)

<comment><USER20> Quack!!!

</comment></comment></comment><comment><USER21> Doesn't work without ajax.googleapis.com. Movements in this town are also tracked by Google.

<comment><USER22> And it tries to load data from googletagmanager.com

I wonder why. Isn't google tag manager a tool to "click together" modules for people who cannot write html?

<comment><USER23> > Isn't google tag manager a tool to "click together" modules for people who > cannot write html?

or would rather not?

</comment></comment></comment><comment><USER24> Unlike almost every other 3D WebGL (or Canvas) demo that gets posted on HN, smartphones were clearly given due consideration and hence this demo works beautifully in Chrome on my ageing Galaxy S6, including dragging around and using a zoom gesture to toggle viewpoint. Very impressed!

</comment><comment><USER25> Pleasantly surprised to see this work smoothly on my iPhone 6s

<comment><USER26> Surprised it runs well on my linux laptop - except that here I can't click the ? which worked fine on my iPhone.

</comment></comment><comment><USER27> This is really neat, love how clean it looks. Any intention on a follow up post with a bit of behind the scenes information?

</comment><comment><USER28> This is less of an infinite town, and more of a camera loop. You can see the houses end up being a simple repetition, and if you find a place that repeats a bit later, and you go very fast, you can see that the cars are also exactly the same (colors) in the same area. So it's definitely a loop.

</comment><comment><USER29> Does anyone have any good advice on getting started building things in 3D using Unity and bringing it to the internet via ThreeJS? I've learned a little bit about threeJS but I'm not sure how to take things out of Unity and into ThreeJS and into my browser.

</comment><comment><USER30> That's weird: I'm seeing a cloud bounce up and down as it slowly floats over the town.

Browser related? Here's my browser info for reference:

Build identifier: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0

<comment><USER8> It's actually an intentional animation. We just thought it looked cute. Interesting to know that it can be interpreted as a bug though.

<comment><USER30> Oh, I wasn't aware of that. Thanks for the clarification.

Yes, it did look like a bug to me because I didn't expect clouds to act like that in what I took to be a simulation of the real world.

</comment></comment></comment><comment><USER31> Very nice demo! Safari really seems to struggle with this (2014 MacBook Pro, High Sierra). Chrome and Firefox show much better performance.

</comment><comment><USER32> Just experienced the difference between Chrome and FireFox.

To be fair, I did have a lot of tabs open in chrome already. Like about 30.

Edit - 47 to be exact.

</comment><comment><USER33> The cloud shadows look like they are in a different direction to the other shadows? Does anyone else see this?

</comment><comment><USER34> Nice work!

I notice that the vehicles start and stop, whats the logic?

Is it doing collison testing?

Anyone seen any instances where it fails and vehicles collide?

<comment><USER35> Yeah they stop when another vehicle is crossing, but they don't seem to sync, so two vehicles sometimes resume driving at the same time and go through each other.

<comment><USER34> Yes, simple collison detection is available out of the box but I can imagine many "corner" cases that would fail and getting ghost vehicles passing through each other.

</comment></comment></comment><comment><USER36> amazing performance and great visual style. i'd love to see it become a playable simcity-like.

</comment><comment><USER37> Where'd you get the assets?

<comment><USER38> Looks like it's from here: [https://www.cgtrader.com/3d-models/exterior/cityscape/simple...](https://www.cgtrader.com/3d-models/exterior/cityscape/simplepoly- city-low-poly-assets)

<comment><USER39> The about page says "Models by SimplePoly". So that's probably it.

</comment></comment></comment><comment><USER40> Noticed a weird shadow on the heli landing pad. And lo, there's a cloud up there!

</comment><comment><USER41> I find myself wanting to do something similar... thanks for the inspiration!

</comment><comment><USER42> Stylistically this reminds me of Onett from Earthbound.

</comment><comment><USER43> Wow, this town has good cell phone coverage :-)

<comment><USER44> They look like radio towers, not cell towers.

<comment><USER45> Wow this town has a lot of radio stations.

</comment></comment></comment><comment><USER46> The cars sometimes drive through one another.

</comment><comment><USER47> Very neat! I really like the visuals.

</comment><comment><USER48> Doesnt work in Firefox Quantum

<comment><USER8> It works for us. Which OS are you on? Also, any error message in the console? Thanks.

<comment><USER48> I'm running FirefoxDeveloperEdition 58.0b5 (64-bit) on MacOS.

Now, after a refresh it worked. But then again a refresh: grey screen. Refreshing with the screen open: It keeps working. But refreshing and then switching tabs quickly, and switching back: grey screen. (however very difficult to reproduce)

Logs only show this: unreachable code after return statement [Learn More]

</comment></comment></comment><comment><USER49> Is it a Unity app exported to HTML5 (w JS and WebGL)?

<comment><USER50> > Made with: Three.js, Blender, Unity.

Seems so.

<comment><USER51> It is very strange. It seems to have a lot of Unity shader code in it. Much of it verbatim from Unity's source code.

But the rest of it is Three.JS. Thus were the assets created in Unity and someone copied the shader code to ensure that they render the same in ThreeJS as in Unity? I am a little confused.

<comment><USER52> Hi, I'm one of the developers. We use Unity as our main scene editor and exporter. We don't use the official WebGL exporter but a custom script that we wrote. In this project, we use it to assemble individual city blocks, that we merge to a single geometry each. We actually don't use Unity shaders at all, they are also custom made.

<comment><USER53> Just curious, why do you do it that way? (i.e. not just exporting from Unity)

<comment><USER54> Don't know about this specific usecase, but Unity exports are heavy. I mean, it compiles C# scripts to C++ and then compiles it and Unity C++ runtime to Javascript. I easily got download sizes in tens of megabytes when trying to use Unity export for simple demos. Meanwhile Three.js is very lightweight and more than enough for such projects.

</comment></comment></comment></comment></comment></comment><comment><USER55> Lovely work.

</comment><comment><USER56> Cool, but a bit uncanny just how realistic it is. Makes me uncomfortable not to know if I'm looking at a simulation or actually flying over a city, as if in an airplane.

</comment><comment><USER57> This is my site

[https://aicochow.github.io/vpn/](https://aicochow.github.io/vpn/)</comment>


Simple CDN for Tailwind CSS - <AUTHOR> http://tailwindcdn.com/ <comment><USER2> So is this a straightforward delivery system for the default CSS file or is there some URL-based way to configure it (custom palette, disable parts etc.)?

<comment><AUTHOR> Currently it is and will be a straightforward delivery system, however it would be a nice idea to have a configurator and generate a cdn url based on that!

</comment></comment><comment><AUTHOR> It's an open source project, you can contribute here [https://github.com/crafty-dwarf/tailwind-cdn](https://github.com/crafty- dwarf/tailwind-cdn)</comment>


Ask HN: What are some tips for making my first tech talk a success? - <AUTHOR> A month from now, I'm giving my first tech talk to a 30+ crowd of local developers at a weekly meetup. I'll be giving will be titled "Intro to Kotlin for Android Development." The audience is primarily web developers with some experience in iOS development, so I will likely be introducing a new language in addition to the basics of Android development. Is there any particular approach you have seen that would be a good fit for such a talk? <comment><USER2> Assuming your audience are beginners (as it is an intro talk), I find it immensely useful when tech talks have slides that follow this kind of pattern:

\- Problem/Feature/Reason why it's useful

\- Code

\- Demo of the problem/feature/reason working (whether recorded or live)

Doing a bunch of live demos is real risky for a first tech talk, but if you practice (I mean really practice, with network access turned off for example), and know your stuff, it's possible.

If you're game to do a demo, I think one of the most important things you can demo is going 0-100 with a small kotlin app on Android. This will require you to make some choices that your audience would normally make themselves (like how to develop the app, not everyone uses android studio), but if Kotlin for Android Development is actually valuable, it should be self-evident from watching it used (you may have to throw in some problems that you solve by writing idiomatic Kotlin, and explain why they would look worse in Java or whatever else).

Also you might want to include these slides (probably just one so people don't lose focus):

\- Options for native android development (to set up the next slide), you might briefly explain things like React Native, Go for android, Java, Scala, Clojure. Hard to keep this to one slide but it is valuable because it makes the person watching feel like they know the landscape, at least at a high level, and motivates the talk.

\- What/Who/When/Why for Kotlin on Android

Here's an excellent talk that came to my mind: [https://www.youtube.com/watch?v=0GzzFeS5cMc](https://www.youtube.com/watch?v=0GzzFeS5cMc)

<comment><AUTHOR> Thanks a lot for the feedback! I'm watching the talk you linked on Youtube right now and taking notes.

I think I'm leaning more against doing a live demo at this point, but I may change my mind as I continue working on my demo material.

Good advice on the slide suggestions. I'll definitely want to cover the Java alternatives on Android and why I prefer Kotlin.

<comment><USER2> Yeah, I've seen a lot of great talks on youtube (there's a ton out there), but as far as real get-started-with-x talks, I can't remember any that really stick out as good examples (I'm sure I've seen some, just can't remember). I remember when the developer in that video implemented the reverse-time feature it was really impressive to watch.

Your talk seems like it might be split between two topics; introduction to android at large, and why use kotlin over the other choices... It might be a little hard to balance both but.

Also, I think I might have mentioned, but the safe way to go with demos is probably to record the parts before hand, then attempt the demo live, and maybe fall back to the recorded part if things go awry.

Good luck!

</comment></comment></comment><comment><USER3> Have you done much public speaking before this? If not, you probably want to practice the talk in front of a small group of friends and get their feedback. Though really the practice is the more important part than the feedback.

<comment><AUTHOR> Back in college almost 10 years ago. I definitely need to practice.</comment></comment>


Show HN: AppApp.io – A better search for the iOS App Store - <AUTHOR> https://appapp.io <comment><USER2> Interesting site. I love the ability to narrow down apps through an advanced search. However, I feel like it rewards apps with keywords in their titles over those that don't. Consider someone searching for "music". It's reasonable for Spotify to show up, or even my app Musi which currently ranks first for that keyword in the App Store since both of those apps heavily involve music. However, on AppApp, none of those are found. Instead, there are mostly music creation apps which generally include music in their titles, versus music listening apps which may not.

If Apple changed their search to work more like this, I would have to change my app name to "Music Player" to stay competitive, and add even more keywords in the title.

As it stands, I feel like Apple rewards popular apps a little too much and I like how this is a more literal search, but there is definitely merit in having a search which has understanding about what an app is about (which is what I believe Apple _tries_ to do with their current App Store search).

<comment><AUTHOR> Thanks for your comment. I do completely agree. The keywords that are entered by the developer for the iOS app are not exposed anywhere (API or otherwise) by Apple (as far as I know), so it is hard for us to index those.

For further phases we are looking into some sort of bayesian categorisation/tagging which can hopefully help with this problem.

<comment><USER3> You might also consider allowing developers to register and enter their keywords.

<comment><AUTHOR> That's a great idea.

</comment></comment></comment></comment><comment><AUTHOR> As to why the world might need another search for the App Store, I have written this blog: [http://blog.appapp.io/post/131747237960/the-raison-detre- of-...](http://blog.appapp.io/post/131747237960/the-raison-detre-of-appappio)

<comment><USER4> Sure, there's always an opportunity for building a better X. I'd like a better google in fact, and the App store has always had poor search.

The question, though, is what is your business model? If it's just a demo of your skills-- great. but if you want people to use it consistently or use it for years to come it needs a business model to sustain it.

Without that, its hard to know whether I should try and remember that this exists or not.

This isn't meant to be mean or anything like that, not even criticism, just my perspective.

<comment><AUTHOR> As a starting point the site is part of the iTunes affiliate scheme. Hosting costs are fairly small, so as long as it covers its costs it'll be live perpetually. We also have other ideas for sources of revenue, this is just the MVP.

</comment></comment></comment><comment><USER5> This is a nice alternative. Bookmarked! As I'm sure you know as a parent by now, the next nice-to-have feature would be to filter against apps that use ads. Worst offenders being full screen video ads you can't skip and banner ads placed close to buttons.

Children are quite vulnerable to believe what they're seeing in the ad verbatim. Then you're the bad guy for not agreeing to get them that game they just saw beeing so great. More importantly though, brainwashing with ads steals the time that was supposed to be spent on something else.

At least your "No IAP" filter already eliminates the awful apps that let children "earn coins" for watching ads.

<comment><AUTHOR> I totally agree. Finding out which apps have ads like that is non-trivial, but we'll certainly look into it.

<comment><USER5> A whole world of new search vectors would open if you scraped and mined the reviews.

</comment></comment></comment><comment><USER6> Have you done any usability testing regarding the choice of a fixed non- scrolling header for search? It's a pet peeve of mine but along with the cookie info footer and my browser chrome, there's a big chunk of my vertical space wasted -- feels like I'm peeping in through a fence. If I want to search, your main page is all about it, and I really don't feel like I need the search thing present at ALL times while looking at what I've already searched for.

<comment><AUTHOR> Formally, no. I have had it beta tested by friends and family, and that is not something that has been mentioned.

I do have sympathy with your view on the desktop version. It originates from the mobile version (which was written first) which has infinite scroll rather than pagination, so I think it is more pertinent to keep the search term and the number of results on screen as the user scrolls down.

I possibly should just remove it from the desktop version.

</comment></comment><comment><USER7> Live search pollutes the browser history with each letter typed. Otherwise - well done!

<comment><AUTHOR> You're right, I'd like to address that in some sort of sensible way. This is just an MVP right now, but thanks for your suggestion (which I agree with)

<comment><USER8> Adding a small delay after someone types a letter and before the API is hit would improve it a bit in the meantime. Also use history.replaceState so you don't add so many entries to the browser history.

Every time I type a letter (or each time I hit backspace), the browser fires off a dozen requests for the search term and all the images for every app in the result. This is a waste of bandwidth and bogs the browser down. I'm all for interactivity but you need to take usability into account a bit.

</comment></comment></comment><comment><USER9> I like it a lot! The only thing that bothered me was how the star ratings show numbers instead of the stars, so I have to look carefully at the ratings before choosing an app.

With a star ____* rating the rating is visual, so I can easily see at a glance what the rating is.

<comment><AUTHOR> Thanks for your comment. I've flip-flopped a bit on that issue, you may be right.

</comment></comment><comment><USER10> Way better than the built in app store search, however I can't see the titles of the apps only the search terms.

<comment><AUTHOR> I suspect what you are seeing are the titles - but the nature of Apple's search encourages App developers to stuff their titles with keywords.

</comment></comment><comment><USER11> This seems working super fast! If you dont mind can we know your tech stack?

P.S awesome work.

<comment><AUTHOR> It's Ember.js on the front end talking to an Algolia API. It's all proxied via CloudFlare, so very few requests hit our server (at Heroku)

</comment></comment><comment><USER12> Great job!

Do you plan on making it a real app for iOS ? Will Apple allow it on AppStore ?

<comment><AUTHOR> I seem to remember seeing somewhere that it wouldn't be allowed. I'll need to research it further to get a definitive answer - it would seem sensible to make an app version if it was allowed.

<comment><USER5> You could make it usable as a "web clip", i.e. an bookmark that you can add to your home screen.

<comment><AUTHOR> Good idea!

</comment></comment></comment></comment><comment><USER13> The back buttons broken :[

<comment><AUTHOR> It's not exactly 'broken'. When you go to the home page it geolocates you, and then forwards you to the correct home page for your location. Admittedly it then makes it feel a bit broken...

<comment><USER14> Putting my browser in a state where the back button doesn't let me leave the site is the definition of breaking the back button. Worse than those back button pop-ups that only fire once (this is like a popup that fires every time). Definitely check out window.history.replaceState as mh- suggests.

<comment><AUTHOR> It should be fixed now.

</comment></comment></comment></comment><comment><USER15> Hey OP, some feedback:

Both our apps appear as top results when "LoyLap" is typed into App Store search. In your results only our merchant app appears when queried with "LoyLap".

<comment><AUTHOR> It should be there now. I think there is an edge case in the indexing logic that skipped your app last time. Marking as will fix...

</comment></comment><comment><USER16> Pretty nice! Can you search by app size? I seem to remember it was exposed by the API.

<comment><AUTHOR> We can add that if you think it'd be a useful feature?

</comment></comment><comment><USER17> Where did you get the data from? Or is it just recent submissions/updates?

<comment><USER18> how would you get recent submissions/updates data ?

<comment><USER17> There are also RSS feeds one can collect.

</comment></comment></comment><comment><USER11> Does app store has some api? Or did you scrap them?

</comment><comment><USER19> looks like a copy of [http://fnd.io](http://fnd.io)

<comment><AUTHOR> fnd.io talks directly to Apple's search API (which is one of our sources). What fnd.io does not let you do is filter results by all the criteria we provide (we consider that our main USP). e.g you can't find pay once games on fnd.io like this: [https://appapp.io/us/genre=Games;has_iap=false;price=%3E=0.9...](https://appapp.io/us/genre=Games;has_iap=false;price=%3E=0.99/search)</comment></comment>


Better Biometrics in Android P - <AUTHOR> https://security.googleblog.com/2018/06/better-biometrics-in-android-p.html <comment><USER2> What's considered a weak biometric? Maybe 2D face recognition?</comment>


What static web site generators would you use? - <AUTHOR>

Hi All,
I need to build a simple static web site. Previously in the past I've played around with StaticMatic <http://staticmatic.rubyforge.org/> and found it quite good.
Howeve the version number does not seem to have changed for a while and you are tied to HAML, not that that is a bad thing, its just it would be nice to be able to use other template languages.
I've also read an article here by Tom Preston-Werner <http://tom.preston-werner.com> about his tool Jekyll <http://github.com/mojombo/jekyll/tree/master>.  It looks very interesting, has anybody used it?  Is it more blog orientated, by that I mean is it harder to use it for a different context?
Finally I did a Google search and found this tool:  <http://webgen.rubyforge.org/>.  Again has anyone used it or got any comments about it.
My requirements are to create a simple 4 page site where the content isn't going to change that often.  I would like to use Markdown / Textile / Haml / ERB. I also like code to be clean and efficient therefore the HTML generator should be pretty small and easy to use.  Ideally I'd like to use Ruby and Ruby gems, but I'm not fussy.
Anyway I'd appreciate your input. Many thanks,
Ben Emson... <comment><USER2> I'm a little biased (I'm the author of webgen :) but I think webgen would suit your needs. You can install it via `gem install webgen`, it runs on Ruby 1.8, 1.9 and JRuby, supports Markdown/Textile/Haml/ERB/... and is easy to use:

* Create your website:

        webgen create my_site

* Render your website:

        cd my_site; webgen

The built website uses only relative URLs, so you can preview it by just opening `my_site/out/index.html`. Adding a page is as simple as adding a file with the extension page to the my_site/src directory. The styling of the site is done via templates, the main template being my_site/src/default.template. You can select from several different styles when creating a website (see `webgen help create`).

Menus, breadcrumb trails, links to translations of the current page are all automatically generated.

You can, if you need/want to, use webgen from a Ruby script:

        require 'webgen/website'
        ws = Webgen::Website.new(ws_directory)  # ws_directory would be the my_site directory in the example above
        ws.render

For more information have a look at the webgen website.

<comment><AUTHOR> Hi gettalong

That looks really interesting - I do a lot of web site work for clients, in Rails, PHP and simple static HTML sites.

I've found that sometimes you want to mock up simple sites without using a framework or a CMS system like Drupal, but want to keep your code DRY.

Also some small companies often won't want to change their data frequently and would rather pay someone to do it for them and I think this is the best tool for the job.

Thanks for you comment I'll have a play with webgen it looks like an interesting project.

Many thanks Ben Emson...

</comment></comment><comment><USER3> _I need to build a simple static web site._

It depends a lot on what you specifically need from the tool, but given what you have used previously, Webby may be your best bet. It is a wonderfully simple yet powerful tool.

<http://webby.rubyforge.org/>

 _I've also read an article here by Tom Preston-Werner <[http://tom.preston- werner.com>](http://tom.preston-werner.com>); about his tool Jekyll_

Jekyll is a nice tool but it is geared toward blogs. Tom noted this as the reason he created it instead of using Webby.

</comment><comment><USER4> Not sure exactly what you are trying to do, and why you would go through the overhead of one of these programs.

Why not just write the html yourself, or use something like google sites?

I think you'd spend more time learning to use one of these tools (and looking for and deciding which one) than it would take you to build a site.

If you really don't think you have the chops for writing your own html, or don't think google sites or something similar is for you, how about having somebody set up a joomla or drupal site for you?</comment>


CEOs and the Candle Problem - <AUTHOR> http://blogs.nature.com/a_mad_hemorrhage/2012/04/02/ceos-and-the-candle-problem

<comment><USER2> Interesting article - but I don't think the author should be so certain of his conclusions.

Just because people take longer to solve the 'difficult' candle problem with financial incentives, does not mean they take longer to solve ALL 'difficult' problems when offered financial incentives...</comment>


Subcompact Publishing - <AUTHOR> http://craigmod.com/journal/subcompact_publishing/

<comment><USER2> Hello HN —

Super duper tl;dr:

\- Christensen's theories of industry disruption fit digital publishing like a glove [1]

\- Marco's The Magazine is a pretty good 'subcompact' example [2]

This essay is the written + expanded version of a talk I gave at The Internet Archive (Books in Browsers) last month: [http://www.youtube.com/watch?v=qmGwM6hWbMY&feature=youtu...](http://www.youtube.com/watch?v=qmGwM6hWbMY&feature=youtu.be)

Watching the video or reading the essay both take about the same amount of time, but the essay has much more information.

You can skip to my UI/UX deconstruction of The Magazine here: [http://craigmod.com/journal/subcompact_publishing/#sub_thema...](http://craigmod.com/journal/subcompact_publishing/#sub_themagazine)

Or, skip to the 'Subcompact Manifesto' here: [http://craigmod.com/journal/subcompact_publishing/#sub_manif...](http://craigmod.com/journal/subcompact_publishing/#sub_manifesto)

[1] Innovator's Dilema; Also: this Neiman Report: [http://www.nieman.harvard.edu/reports/article/102798/Breakin...](http://www.nieman.harvard.edu/reports/article/102798/Breaking- News.aspx)

[2] <http://the-magazine.org/>

<comment><USER3> Your tl;dr is a bunch of links. What is the one-sentence tl;dr, because after reading the OP I didn't really see the point?

<comment><USER2> nelsonweiss does a good job up above.

</comment></comment></comment><comment><USER4> Short sweet tl;dr

Online publishing nonsensically adopts many of the practices of offline publishing.

It doesn't need to, and could benefit from adopting "Small issue sizes (3-7 articles / issue), Small file sizes, Digital-aware subscription prices, Fluid publishing schedule[s], Scroll [instead of pagination], Clear navigation, HTML(ish) [formatting], [and] Touching the open web [not just platforms]".

</comment><comment><USER4> Okay- Question for you Cmod: Why do you think that keeping issues at all is a good thing?

Issues is one of those throwbacks to physical publishing. When you have to physically print and distribute, issues are a good thing... but online you can just publish an article when it's ready.

You mentioned how you think "edge" is important, so I would guess one of your arguments might be that a "publish on completion" stream is the exact opposite of edge. However, couldn't you just create artificial edges? For instance, showing the articles for the past 7 days?

<comment><USER2> Issues certainly create edges. They also allow for thematic grouping (which is good for editorial guidance).

Mainly though, they limit the number of times a reader is pinged. I'm a big advocate for grouping all notifications, not just 'content' — only notify me if #_notifications > x. Issues can be a kind of inherent frequency limiter.

That said, they're absolutely not necessary and most online publishing (rightly) has no concept of issues.

 _"However, couldn't you just create artificial edges? For instance, showing the articles for the past 7 days?"_

Yes — and I think more apps should allow for this.

Facebook is a great example (IMO, but clearly not in the opinion of many others) of doing just this — taking a near infinite stream of one-offs and grouping them based on your Facebook use frequency / habits. Twitter's (Summify) summary articles are another good implementation of this: _what happened in my stream yesterday?_

<comment><USER4> Next question- what amount of money constitutes a digital aware subscription price? What range? And how are you determining this price?

Second (though related), what is the place of advertising in this theoretical subcompact publication?

</comment></comment></comment><comment><USER5> I agree with basically everything in this article... except the paid subscription model, which to me seems another instance of pointlessly aping the print publishing world.

In the print world, you have to charge each reader because there's an actual cost associated with producing each physical copy, but this is not the case for digital products, where distribution is effectively free. And since free crowds out paid, it's extremely difficult for a paid digital magazine to build up a following. (Thought experiment: if this article itself had been published behind a paywall, how many would have read it, and would it have ended up on HN?)

Now, of course there is still a cost associated with actually creating quality content. The key to success will be finding a way to pay for it without charging readers and thus kneecapping distribution.

Too short, read more: [http://gyrovague.com/2012/06/28/why-the-web-will-gut- paid-e-...](http://gyrovague.com/2012/06/28/why-the-web-will-gut-paid-e-books- and-apps-and-why-free-can-pay-for-authors-and-publishers/)

</comment><comment><USER6> Great article. It would be neat to see what the backend for the Magazine looks like and whether Marco Arment (or someone else) will make it easier to produce something like The Magazine.</comment>


Hackathons are like gyms - <AUTHOR> https://medium.com/hackathons-anonymous/7ebcd6bfda26

<comment><USER2> I love the idea that a hackathon is a more supportive environment for learning than the typical school or even home. However, I urge those who are learning to code at hackathons to take the time afterwards to more comprehensively understand the concepts you picked up in the rushed environment of a hackathon. Rushed learning can result in some serious deficiencies and gaps in knowledge that will be an impediment to future productivity.

<comment><USER3> I think the biggest bottleneck by far in this space is getting people inspired to learn. More than it being rushed learning or comprehensive learning, the biggest benefit hackathons have is to get people learning to begin with :)

not to mention the great community that springs up out of it!

</comment></comment><comment><USER4> Not so sure. I like learning at a pace in which I'm really understanding the technologies that I'm picking up. For PennApps, we do a series of tech talks over the course the week before the hackathon, and I encourage students who don't know how to code to attend those talks. I think "learning" at a hackathon can leave a lot of gaps in knowledge, which is not necessarily terrible but not the strategy I would immediately advise.

<comment><USER3> I think the hackathon is more for helping people dive in and go from 0 to something. After that, learning more comprehensively is definitely crucial.

</comment></comment><comment><USER5> Trying to get new people to come to hackathons is why we started CodeDay.

It's actually an extremely effective way to give new people a wide basing in computer science and, more importantly, get them excited.

I'd love to see more marketing to new people in regards to hackathons.

<comment><AUTHOR> It surprises me that organizations like Code.org don't take advantage of hackathons to spread their message.

Why hasn't this happened yet?

<comment><USER6> check out www.tjhackathon.com. We're planning on expanding to various locations to do just that.

Code.org so far has just been a bunch of big names putting their name on something to make noise. Very little real change from what I've seen.

</comment></comment></comment><comment><USER7> Obviously there are gaps in what you can learn at a hackathon. You guys need to stop beating the point there. However, provide a situation in which you can learn as much as you do so quickly as you do at a hackathon, and I guarantee you can't.

</comment><comment><USER8> Hackathons have changed my life. It is what took me to the next level in my coding ability, it helped me find out what I was passionate about, and I met some of the coolest people I have ever met.

<comment><USER3> would you have been in CS without hackathons though?

</comment></comment><comment><USER9> hackathons are like gyms</comment>


Ask HN: Which Clojure Editor? Emacs, Sublime, or Lighttable? - <AUTHOR>

<comment><USER2> I've been using LightTable, but plan on switching to Emacs soon. The only reason I haven't done so already is learning Clojure is challenging enough without also coming to grips with a new editor :)

</comment><comment><USER3> Definitely Lighttable!

</comment><comment><USER4> nightcode or lighttable or sublime in that order probably

<comment><AUTHOR> Thanks I didn't know about Nightcode!</comment></comment>


Rybka, the world's best chess engine, caught plagiarizing open-source software - <AUTHOR> http://www.extremetech.com/extreme/88610-rybka-the-worlds-best-chess-engine-outlawed-and-disqualified

<comment><USER2> What's funny is that they made a huge deal about Firebird being a clone of Rybka...when it was likely just based off of Fruit.

<http://www.chessvibes.com/reports/chess-engine-controversy/>

</comment><comment><USER3> <http://news.ycombinator.com/item?id=2709401></comment>


The spiped secure pipe daemon - <AUTHOR> http://www.daemonology.net/blog/2011-07-04-spiped-secure-pipe-daemon.html <comment><USER2> Nice. One nit: any sane OS will provide near-perfect randomness from /dev/urandom (by restoring the last RNG state from disk), but you're bound to run into some idiotic Linux distro which doesn't; its fans will claim that you should have used /dev/random. (A quick search turns up <https://dev.openwrt.org/ticket/8687>, which suggests that not saving the RNG state may be more common than I'd hoped.)

A one-line comment in "Security requirements", or even an option to read from /dev/random, may be a good idea.

I tried compiling it on OpenBSD; you should probably #include <string.h> in lib/events/events_network.c for memset() as used in FD_ZERO (see OpenBSD select(2)). OpenBSD has no -lrt either, so I just removed that. It compiles and passes a quick localhost test with these changes.

<comment><AUTHOR> _A one-line comment in "Security requirements", or even an option to read from /dev/random, may be a good idea._

Good point. I'm used to FreeBSD, where /dev/urandom and /dev/random are the same device.

 _you should probably #include <string.h> in lib/events/events_network.c for memset() as used in FD_ZERO_

POSIX says that <sys/select.h> is all you need.

 _OpenBSD has no -lrt either, so I just removed that._

POSIX says that -lrt must work (having a librt isn't required, but if you don't have one the compiler must ignore -lrt).

Hopefully these will either get fixed in OpenBSD or as patches in ports/security/spiped if someone decides to add spiped to the OpenBSD ports tree.

<comment><USER3> Thanks for pointing these things out. We can probably fix it.

<comment><AUTHOR> FWIW, Darwin also gets -lrt wrong, so you're not alone with that one. I was actually rather surprised when I found this stipulation.

</comment></comment></comment></comment><comment><USER4> There's a lot of code in stunnel, but much of it isn't in security-critical code paths. I'm not sure stunnel <-> stud is an apples-apples comparison.

<comment><AUTHOR> Unless 95% of stunnel's code is in non-security-critical code paths, it still has considerably more security-critical code than stud.

<comment><USER4> I've read both stunnel and stud and 95% might ... just ... be on the high side of a reasonable estimate there. Again, I'm saying: stud <-> stunnel is not an apples-apples comparison.

The reality here, and I think you should just come out and say it, is that the rationale behind spiped is that you don't trust SSL/TLS _period_.

What's the deal with the per-message padding scheme here? Is this a tradeoff against rekeying?

<comment><AUTHOR> _The reality here, and I think you should just come out and say it, is that the rationale behind spiped is that you don't trust SSL/TLS period._

That's part of it, sure. But SSL/TLS also doesn't provide client authentication (unless you use client SSL keys, which is absolutely guaranteed to have security holes given that nobody ever uses them).

 _What's the deal with the per-message padding scheme here?_

1\. Makes the code much simpler and less error-prone (no need to read variable-length records from the network).

2\. Cuts down on information leakage. I'm planning on using this for kivaloo, which uses variable-length records -- I don't want to expose the lengths of account names or suchlike.

<comment><USER4> Client SSL certificates are very common in non-web TLS settings.

</comment></comment></comment></comment></comment><comment><USER5> Why not use OpenVPN for secure tunnels?

I used to use ssh tunnels for tunneling irc from irssi-proxy to my local machine (since I don't trust irssi's authentication around the proxy). This involved several steps: binding the proxy to 127.0.0.1, and then sshing in from my desktop and forwarding the ports. And, with two transport layers, my irc client would disconnect if the irc connection failed or if the ssh connection failed. This was annoying.

I eventually switched to OpenVPN. I run a server on one of my hosts, and then the other networks I control connect to that and share their networks. The result is that I can bind irssi-proxy to the 10.0.42.0 interface and then directly connect from any other machine on my network.

This ends up being much less of a pain than the other setup, scales to many more services, and lets me do cool things like ssh-ing to my phone when it's on Sprint's network and my laptop is on a cafe's network.

(Oh, and if you do this yourself, don't use anything in 10.0.0.0/16 for your internal network; VPN or otherwise. You will end up in some coffee shop that reserves the whole /16 for itself when all it needs is some random /8, and then nothing works.)

<comment><USER4> First, both SSH and OpenVPN are much more complicated than spiped, and thus more likely to have security flaws. OpenVPN as you know incorporates OpenSSL and makes use of an even greater fraction of its code than stunnel; Colin's primary goal in building spiped seems to have been avoiding the need for stunnel (or even stud).

Second, if all you're trying to do is hook one discrete component up to another, a full-on VPN isn't just overkill, it's also unnecessarily dangerous, since now you have to configure the network stacks to ensure that only the traffic you intended to allow is going to be able to get through after a minor compromise.

</comment></comment><comment><USER6> So you're doing DH negotiation and AES yourself because "stunnel is 10k lines of code"?

What could possibly go wrong?

<comment><USER4> This is a reasonable comment, but you should read spiped before coming to a conclusion; in this one case, we're talking about (for instance) DH code from someone who writes his own blinded modexp. I don't see anything crazy in it.

<comment><USER6> I spent about five minutes poking through it and nothing stuck out... but when I stopped I contemplated how many eyeballs have done the same thing to stunnel/gnutls already.

I didn't reach any conclusion from my quick look, but was definitely put off by the "it's big so it must be insecure" view taken by the author.

<comment><AUTHOR> I'm not saying that stunnel _is_ insecure. I'm saying that I don't _trust_ it to be secure.

<comment><USER6> What OS kernel do you run? Also, what's the next question I'm about to ask you after you answer that?

<comment><USER4> He's the FreeBSD security officer. What were you thinking was going to stick out when you read through it? What mistakes did you look for?

<comment><USER6> Didn't know that, I'd never heard of him before (I haven't run BSD in years, and when I did it wasn't FreeBSD).

Most of the time when someone posts a "look what I just implemented in C" to HN it's, well, not great. As I mentioned I only looked for five minutes, but I looked for really basic general programming errors, low-hanging fruit kind of stuff. That's enough to effectively cull a lot of the noise that gets posted here.

His code is good - I just wonder why someone'd go to the effort (which is much higher than most other programming projects, due to the consequences of a bug) when we already have well-worn codebases for stuff /almost/ exactly like this, considering the tightrope-of-vigilance that is correctly implementing crypto protocols.

I understand now that he wants a PSK vs. stunnel/TLS's certs-on-both-ends method, but effectively it only really differs in connection setup, as TLS (the way I understand it to be generally used) does symmetric crypto for the payload data anyway (after key setup).

PS: His project is the first time I've encountered the use of gotos resulting in _cleaner_ code than without them. :)

<comment><AUTHOR> _I just wonder why someone'd go to the effort_

It wasn't that much effort. Almost everything under /lib/ I had already written as part of tarsnap or kivaloo; I spent maybe 10 hours making minor tweaks and cleanups to that code (which will be useful when I next use the library code anyway) and somewhere around 40 hours figuring out the protocol and writing the spiped specific code.

Having a simple secure pipe tool will save me far more time than that, once you count things like wanting to programmatically set up encrypted pipes (for which spiped's command line and arbitrary key is much better than stunnel's configuration file and SSL certificates).

 _effectively it only really differs in connection setup_

And connection setup is a big deal. That's where almost all the vulnerabilities happen. In SSL, you go through a complicated handshake before you can decide that the client you're talking to doesn't have the right keys; in spiped, you exchange 256-bit nonces, and then if _the very next buffer you read_ doesn't have right right HMAC, the connection is dropped. Evil data never meets asymmetric crypto. If an attacker doesn't have the key, they can't force you to burn any significant amount of CPU time.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Awesome work, Colin. I can think of more than a few uses for a lightweight and secure pipe forwarder. I also enjoyed reading your earlier article about keeping OpenSSL and Apache separate.

I have a question though - in the beginning of your post, you talk about STUD. Did you replace stunnel with STUD, or not just yet? Just wondering how that went.

<comment><AUTHOR> _Did you replace stunnel with STUD, or not just yet?_

Not yet. That's waiting for the next time I context-switch into sysadmin mode.

</comment></comment><comment><USER8> Is the example in the spiped readme the equivalent of the following using socat?

# smtp server

socat OPENSSL-LISTEN:8025,reuseaddr,fork,cert=$CERT,key=$KEY,cafile=$CAFILE TCP:127.0.0.1:25

# smtp client

socat TCP-LISTEN:25,reuseaddr,fork OPENSSL- CONNECT:$SERVERNAME:8025,cert=$CERT,key=$KEY,cafile=$CAFILE

<comment><AUTHOR> Yes, for a sufficiently weak definition of "equivalent". spiped doesn't use OpenSSL and doesn't need to fork off separata processes for each connection, for instance.</comment></comment>


IPhone fart app pulls in nearly $10,000 a day - <AUTHOR> http://venturebeat.com/2008/12/23/iphone-fart-app-pulls-in-nearly-10000-a-day/ <comment><USER2> This is one of the things I love about being in the startup biz. On one side there's change-the-world apps that dozens of developers labor over for years at a time, slowly building a customer base, nurturing an idea with great business execution into something that provides real, tangible value to folks.

And then there's i-Fart, which could've been made by some guy with a hangover during a weekend spent picking his nose and eating stale pizza while watching re-runs of Gilligan's Island.

This is a great time to be alive!

<comment><USER3> _... which could've been made by some guy with a hangover during a weekend spent picking his nose and eating stale pizza while watching re-runs of Gilligan's Island ..._

That isn't how people in a startup are supposed to work? Shoot, I've been doing it all wrong.

</comment></comment><comment><USER4> I am experiencing the same emotions as when I heard about the Million Dollar web page, Tension Sheets, imageshack, plentyoffish...

<comment><USER5> Would that be the same feelings I'm experiencing? Namely a conviction that _now_ all the easy-money one-offs have been done and _this time_ there _can't_ be any left?

</comment></comment><comment><USER6> But they won't approve an app that lets you receive podcasts via RSS.

<comment><USER7> Because they were adding that feature themselves in the next OS update.

<comment><USER6> So you're saying fart sounds won't be in any future OS update?

<comment><USER8> Shit. I'm going back to Ubuntu.

</comment></comment></comment></comment><comment><USER9> Stop throwing sheep.

<http://news.cnet.com/8301-13577_3-10045321-36.html>

<comment><USER10> do something worthy

<comment><USER11> Yes like make 10K a day and putting towards your company so you can then do something worthy cause you have bank!

</comment></comment></comment><comment><USER12> This is both funny and sad.

<comment><USER13> I simply find it sad. Not because all these apps were made -- there's obviously money in it, so whatever, free market and so forth. What's sad is... there's money in it.

<comment><USER3> Just intellectually curious -- why is that saddening? My thoughts are, people can do what they'd like with their money.

<comment><USER8> I think it's sad, not on the part of the developers, but on the people who enable apps like this to be worth making.

<comment><USER14> How mighty of you. You can buy silly mechanical fart machines, cds of farts, whoopee cushions, etc - all of which are many times more expensive (and less fancy) than iFart. So all those people that are looking for a tech bargain and think loud stinking gas emitted from a human anus is hilarious are in luck.

Outside of your self-righteous indignation, of course.

</comment></comment></comment></comment></comment><comment><USER15> I guess it's time to whip up my iFart clone for Android...

</comment><comment><USER16> As much as I'd like to create an interesting but small iPhone app, this makes me seriously wonder if the people buying iPhone apps is much more mainstream (e.g. college or high school or even grade school) than we realize.

I wonder how many times his fart app was rejected. My guess is it will be hard to unseat his app (Facebook effects).

This is like Facebook apps but with real monetization.

<comment><USER17> The top earning Facebook app has made more money than the top iPhone app by a factor of 5 or more. There is nearly 50 million dollars in VC money funding companies who started doing only GAMES on Facebook. Dont fool yourself, having a price tag does not imply higher earning potential.

<comment><USER16> Yes but Facebook does not host your app. I'm pretty sure Slide's infrastructure (and administrative) costs are significant.

<comment><USER17> I'm not even talking about Slide, I'm talking SGN, Zynga, Playfish. These companies were all making bank before they had to invest in infrastructure. Plus, Facebook offers free starter hosting through Joyent.

</comment></comment></comment></comment><comment><USER18> With the global economy under siege, _this_ is the kind of innovation we need to raise standards of living.

</comment><comment><USER19> Its all right talking about "$xxxxx a day" — but how long will that last? I think its better to create something useful/fun which people won't get bored of within 5 minutes and that can be updated later. Even if its just for your own self respect — I really wouldn't want to be the guy who "created the popular iPhone fart app". :P

<comment><USER20> Can't be updated? But think about all the different kinds of fart sounds that could be added!!! _eyeroll_

<comment> puzzle-out Lots of potential for personalisation - doesn't everyone prefer their own?

</comment></comment></comment><comment><USER21> I used to think that app was a waste. I even made negative comments about it on HN. But I was heading to Christmas dinner with my girlfriend's family and figured I'd buy an app to help me entertain the kids. That fart program was perfect. It made everyone laugh.

</comment><comment><USER22> These apps just emit flatuence noises or am I missing a much greater feature set?

<comment><USER23> Like what? An SBD option?

<comment><USER23> Actually, this gave me an idea for another app. In Japan, in the female restrooms (i'm told) they have these machines that emit sounds as cover for doing one's business. I think they are called "Princess Flush" or something. I could definitely see (hear?) a market for this as an iPhone app....

</comment></comment></comment><comment><USER24> It's over $9000!

<comment><USER24> Yaaaaouch! Seafood soup is NOT on the menu!</comment></comment>


Apple to Ban Vaping Apps from Its Store - <AUTHOR> https://www.nytimes.com/2019/11/15/business/apple-vaping-apps.html <comment><USER2> This also includes the Pax app (used for vaping canabis flower) having nothing to do with any of the e-juice related incidents lately. Pretty broad stroke :/</comment>


Facebook Says First-Person Christchurch Video Foiled AI System - <AUTHOR> https://www.bloomberg.com/news/articles/2019-04-24/facebook-says-first-person-christchurch-video-foiled-ai-system <comment><USER2> A local low power tv station has a far smaller reach than facebook but a significant infraction will doom the owners of it real fast. But its ok for facebook to show murder rape and mayhem.</comment>


Longevity in JavaScript Frameworks - <AUTHOR> http://blog.bitovi.com/longevity-or-lack-thereof-in-javascript-frameworks/ <comment><USER2> <TL; DR;> Creators of CanJS think you should use CanJS.

Honestly; I have a hard time taking this article seriously when they put Backbone & Knockout into the "stagnation" category, but CANjs into the "safe bet" area. Both Backbone and Knockout are continually maintained and have done a good job with backwards compatibility.

<comment><USER3> Yes, and I think we do a decent job of highlighting why.

Backbone/Knockout may be well maintained but their scope is fixed. CanJS has gone from the times of $.widget() to <app-component> while maintaining backward compatibility.

<comment><USER4> Just the fact that this is a blatant advertorial makes it hard for anyone to take your article seriously. Your arguments are valid and I admire your research but your presentation discounted all the value you provided with your article. If I were you I would have left out your attempt to "sell" your project and just mention it briefly at the end. If people actually agree with you, they would have been interested anyway. But as soon as you started talking about CanJS the credibility fell to 0

<comment><USER3> Thank you, I get the sense that you're not trying to be overly negative. But I'm also slightly confused. If you can't gain credibility with valid arguments and research, how else can you?

<comment><USER4> The article as is right now, won't be shared as much as could have been if it had objective tone. What I've seen a lot of people do is make a useful and objective argument about what the message they're trying to convey and then maybe at the end mention their message briefly. That's how people build credibility. Check out all "Crunch Network" posts on TechCrunch. Even though most of the writers behind those articles _do_ have agenda (they all have some stakes in the subject matter), a lot of those articles are useful. Since the content is useful, a lot of people share them and there's no lost credibility.

</comment></comment></comment></comment></comment><comment><USER5> As a counterpoint: is your JS webapp really going to live, in its current form, for 5 years? Experience has taught me that there have been enough shifts - to mobile, especially - that betting in the long term like this might not be worth it. If you've structured your app well, the front-end JS is separated from the backend APIs, etc. etc. - a rewrite of that is not a rewrite of the entire app. So if React speeds your site up by a factor of whatever, go for it.

In any case, even if it _is_ , surely an older framework is fine? I see Backbone in the "slow or stagnated innovation" part of the chart - it isn't broken. It works fine. Seems confusing to simultaneously complain about the web framework "industry" moving too fast, and individual frameworks moving too slow.

<comment><USER6> > is your JS webapp really going to live, in its current form, for 5 years?

Pretty much yes. Almost every single large web app I've ever written is still in use. And many of them are sort of frozen in time with whatever technology and techniques were popular at the time. There is no financial reason to rewrite them. Some have gone through major technological shifts (but not rewrites) if I bet on the wrong technology for that project.

When I was 20 years old, 5 years seemed a long time and would have never expected any of my software to be in constant use 15 to 20 years later.

<comment><USER5> I suspect this depends on what area you work in. If you're making corporate webapps, they'll stick around for a long time (hell, they probably still need to support IE7) but if you're consumer facing, things like mobile would be far more likely to require a rewrite.

(for the record, I'm not 20 years old either. However, an decade old C# desktop app I wrote back when I was is still in use at an old corporate workplace)

<comment><USER6> All my early work was in consumer web sites and applications. One of my oldest sites is a popular consumer/professional news and review site in a popular niche. There have been several failed attempts at a redesign over the years but it still chugs along and makes money. Absolutely no attempt has ever been made to make it work on mobile and that would definitely be a design requirement now. The back-end even has a nifty Ajax-like component that should still work in _Netscape 4_.

I do corporate web applications now and there is a lot of pressure to support modern browsers and mobile.

</comment></comment></comment></comment><comment><USER7> I don't know how Bitovi can bash other frameworks for breaking compatability on major versions, when they completely changed the concepts of JMVC in version 3.3. They also stagnated for 2 years between version 3.2 and 3.3.

> _If your project chose JavaScriptMVC in 2007, you would have made a wise > decision, giving your team an upgrade path to a modern application for the > past 8.5 years._

This is kinda funny to me because I know it's untrue. The product I work on in my day job is based on JMVC 3.2 and we can't upgrade to 3.3 because of the size of our app and the amount of refactoring work that would need to be done to make it work with the new concepts.

<comment><USER8> Changing concepts is natural as best practices evolve. 3.3 introduced live binding, but it didn't break any of the older ways of writing apps.

3.2 to 3.3 is actually mostly syntax changes that are documented in the guide linked in the other comment.

What specifically is preventing you from upgrading? If you want any help or tips, please reach out and we'll gladly help you or give some pointers.

</comment></comment><comment><USER9> Javascript frameworks have the same problem that PHP frameworks have: the language is built for the problem they are trying to solve so it's easy to invent new ways to do it. That leads to option saturation and people creating solutions to address the drawback they found in another approach.

That's the reason I have a REALLY hard time committing to any Javascript framework with more than a passing learning curve or a set of rules that wants your whole application to follow (and marry).

For that reason, I'd generally stuck with just using jQuery until I was introduced to React. React seems to go at the problem from a "realistic use" perspective that flows well with small reusable components without requiring full marriage to use it. It's the most well thought out one that I've seen.

That said, I'm going to continue being a skeptical curmudgeon.

</comment><comment><USER10> Why do frameworks need to innovate? I'd much rather have a framework that releases fixes than one that "innovates often". Frameworks should start out innovative and slow down. Things change too fast to expect an "innovative framework" to be backwards compatable.

<comment><USER3> It's fair to have compromised your expectations of frameworks - since there aren't many that have been around for long - but Bitovi and its clients have not. Our libraries are both backward compatible and constantly innovating.

</comment></comment><comment><USER11> On an unrelated note, your page took 1.2 minutes to load completely. And I have very fast internet connection.

<comment><USER8> Sorry about that, having some blog issues due to a lot of load today. It will be back up in the next 20 minutes.

</comment></comment><comment><USER12> There is a tendency on HN to only consider product- or service-oriented software development. That's fine, I understand that tendency, it's kind of what we all _want_ to do.

But there is a LOT more consultoware in the world. And a lot of it runs in the browser on corporate intranets, where _IF_ it ever gets updates past the first year after release, it will probably be by a completely different team. And by different team, that could either mean a completely different consulting company, or a completely different set of developers in the original company [0].

I know for a fact that there is JS code that I have written that has been in use, unchanged, for 10 years. That's not to say that I wrote amazing code. I didn't write anything good 10 years ago (and probably don't 10 years later, but that's a different issue). That code got written, the system got installed, and nobody ever went back to change anything in it. I'm sure the database server crashes once every two days and they just have a policy to reset the server every morning.

So yes, you absolutely can expect code you write to last for 5+ years.

[0] And that could be be either because the consulting company moves their A-Team around on new projects and puts their B- and C-Teams on long-term- support, or it could be because the company perpetually assigns teams to projects, and bored developers quit to new companies.

</comment><comment><USER13> I really hope React plays out better than Angular. And with FB using it for their web and mobile apps, it seems a good bet. Angular and Ember seem to move into the React direction, which lets React shine even more.

I was forced to switch from ExtJS to Ember to React, so I don't mind learning another framework in the next years. But it would be nice if I could work with my React skills for 5 or more, haha.

</comment><comment><USER14> Server is unreachable; archived version: [https://archive.is/i8t9w](https://archive.is/i8t9w)

</comment><comment><USER15> It ends up a bit commercially, but they still make a valid point I think.

<comment><USER16> I agree and i would add that betting on a framework is a huge risk, relying on a library is far less dangerous. In the comparison there are some of both so the example are a bit misleading. For example to my knowledge knockout is far from stagnating, it does 1 thing only and it does it well, you can easy replace it incrementally in any application.

<comment><USER17> I completely agree with you on knockout. All versions are backwards compatible, just change the version number and you can enjoy the new features, I'm very happy I went with ko over angular (of course angular does more things so it's not a fair comparison, but things I do not need).

</comment></comment></comment><comment><USER18> The only thing you lose from a non-evolving framework is the new features and bug-fixes they provide. You can fork it and fix the bugs yourselves, and losing the new features is kind of whatever - it had enough to convince you to use it in the first place.

As long as you're using the best tool for the job you have now, you'll probably be fine.

<comment><USER19> You _can_ rewrite an app instead of maintaining it for years, in which case choosing a non-evolving framework is perfectly fine. Over time, this approach doesn't fit very well into an agile development methodology. Choosing a non- evolving framework almost guarantees that your app will become a "legacy" app one day.

</comment></comment><comment><USER20> The Dojo toolkit has been around since 2005. If you only count stable releases then it still beats Javascript MVC as JSMVC 1.0 was released in early 2008 and Dojo 1.0 was released in November of 2007.

</comment><comment><USER21> /aside Is most adoption of new frameworks due to old developers switching, or new developers entering the market?

JS frameworks are the Drosophila of software, which is surely partly due to the accessibility and popularity of JS, its flexibility and flaws, and also of course that the problem frameworks solve gets better understood and then changes, and the solutions improve. But perhaps also, JS developers themselves are the Drosophila of software developers, quickly entering and exiting the JS field. In many fields, new blood drives adoption.

</comment><comment><USER22> Also worth noting: the same insight is valid w.r.t. languages, databases, etc.

One rule of thumb I've heard is that you should incorporate _at most_ one "new" piece of tech into any given project.

</comment><comment><USER23> The good news is that with ES6/7 and the advent (hopefully) of web components, frameworks lose some of their significance. As things are now, what you need from a framework is a good router and a template engine as glue for the components. Most of the logic can be made portable.

There's of course still some work to be done on reusability of UI components — seeing as Angular, React, and Aurelia are each building their own Material Design implementation.

<comment><USER24> > frameworks lose some of their significance

no they wont, see server side languages. There will be dozens of frameworks for ES6/7 ... why do you think AngularJS and co get rewritten from scratch using some ES6/7 dialect ? You can argue AngularJS will be a set of decoupled libs, that wont be the case for what matters, the view.

> There's of course still some work to be done on reusability of UI components > — seeing as Angular, React, and Aurelia are each building their own Material > Design implementation.

Not sure why you're talking about material design, and why it matters when it's some vague UX spec produced by Google. Did you mean webcomponents ?

<comment><USER23> > There will be dozens of frameworks for ES6/7

Sure, but you don't have to have all your application logic written using a framework-specific class factory, linked through a framework-specific module system. That means code will be more portable.

> Not sure why you're talking about material design, and why it matters when > it's some vague UX spec produced by Google.

It's a very precise UI specification, so theoretically a single implementation would be enough. I am just saying that there is no universally compatible Web Component package format in wide use yet.

</comment></comment></comment><comment><USER25> As the lead author of JMVC, CanJS, StealJS, etc, let me try to address some of the criticisms of this article. I didn't write it, but I reviewed it.

Yes, this is a blatant advertisement. We worked hard on these open source project, believe they are great, and were trying to argue for their use from a commonly overlooked perspective. It should surprise no one that an article on our site advocates for one of our open source projects. I don't think arguing for something you benefit from should disqualify the argument. Instead, it should make any claims we make fall under more intense scrutiny.

Now about longevity, there really isn't a fair comparison. JavaScriptMVC is far older then Backbone, Knockout, Angular and React. They, for the most part, haven't even had to evolve. Their technology is, for the most part, still pretty modern. We'll see how they do.

Here's how JavaScriptMVC evolved:

JavaScriptMVC started on PrototypeJS. It did almost everything a Backbone + RequireJS + Karma + DocJS setup does today. Except much worse! It used:

\- PrototypeJS (jQuery had only first released)

\- RhinoJS (the only viable server-side JS runtime)

\- EJS for templates like `<%= foo %>`

\- Steal syntax for loading scripts `steal(dependencies)`

\- Selenium for test driving

It had the only working "event delegation" system. This was one of its big features. It also had:

\- basic modeling

\- basic routing

Since that time, we've probably done more then anyone else to adapt and evolve the tools and technology so a reasonable person could upgrade. Some of my favorite highlights:

1\. We updated StealJS to support AMD/CJS/ES6 syntaxes while still supporting the old steal syntax. We also migrated its build system from RhinoJS to NodeJS.

2\. We swapped out Prototype for a compatibility layer that runs on jQuery / Zepto / Dojo / Mootools / YUI 3\. I helped jQuery add event delegation so we could drop it from JMVC in jQuery 1.4.

4\. We added live-binding EJS templates.

5\. We added live-binding Handlebars-like templates. And then re-wrote that again to be 2x faster.

6\. We added custom elements, two-way bindings.

7\. I'm currently rewriting how we do data-connection: [http://connect.canjs.com/](http://connect.canjs.com/), while still providing a backwards compatible version: [http://connect.canjs.com/doc/can- connect%7Ccan%7Cmodel.html](http://connect.canjs.com/doc/can- connect%7Ccan%7Cmodel.html)

8\. Live-reload technology

9\. A progressive bundling algorithm.

10\. Migrated documentjs from Rhino to NodeJS, make it support multi-versioned docs.

If this article had come out 3-4 weeks from now you'll see we added:

1\. Server-side rendering (Isomorphic / Universal JavaScript)

2\. Worker-thread rendering with virtual dom merges.

We started when JavaScript was in its infancy and managed to evolve our tools and technology to keep pace with innovation constantly happening in our space. I really don't think there's another project that's undergone such a transformation.

When Angular was released, people thought putting click handlers back in a template was silly. Same with React's Virtual DOM approach. Those things have turned out to be great. We've added them (or are just about to).

We've tried to keep changes as small as possible between major versions. I think we've walked the line well between change and backwards compatibility.

So in the end, we're very proud of these accomplishments. We believe they are unique and mean something. That's what this article was about.

Btw, I give a free weekly JS training tomorrow. Its got open Q+A at the end if anyone wants to discuss more, you can join it here: [https://plus.google.com/u/1/b/117481170193954630503/events/c...](https://plus.google.com/u/1/b/117481170193954630503/events/ceruatammm7f10roacto41borkc) Open QA will be at approx. 12:45 CST.

</comment><comment><USER26> The _real_ lesson is that you should be using modular frameworks, not monolithic ones.

</comment><comment><USER27> ExtJS dates back to 2006 -- not 2009. It had a good run of ~9 years.

\- former employee

</comment><comment><USER28> Bottom line: consider jQuery before any fancy hot XXX.js framework

<comment><USER29> Consider vanilla JS before jQuery. ;)

Frameworks are useful abstractions for getting a product shipped in a reasonable timeframe. At some point, in your growth as a developer, you _should_ understand how to implement things in your language of choice from first principles. However, "ship it" is not necessarily a conducive mantra to learning the intricacies of a language, design patterns, et cetera.

On top of that, it's really damn hard to find good engineers who can work from first principles that aren't already in highly-paid, competitive positions. This is why frameworks flourish. They substantially lower the barrier to entry for creating product.

<comment><USER19> > They substantially lower the barrier to entry for creating product.

It goes further than this: a good framework can lower the barrier to writing maintainable, modular code. Sometimes people just need a nudge to follow good practices.

<comment><USER29> Yeah, but this can be a crapshoot. ;)

Many JS frameworks enforce their own brand of modularity (complete with boilerplate) that isn't transferrable to other projects, frameworks or languages.

They don't necessarily teach you how to write _modular code_ in general, just how to write _modules within their architecture_. There's a difference.

Edit: Not to say there isn't value in introducing a newbie developer to modules. Just not all frameworks are created equal. :)

<comment><USER30> e.g. Angular</comment></comment></comment></comment></comment>


Will Gutenberg replace popular page builders? Here's my thoughts - <AUTHOR> https://kevinhq.com/will-gutenberg-replace-page-builders/ <comment><USER2> Will myself, my clients, my custom code for my specific WP ecosystem, and our content be replaced by Gutenberg? This is a question I have a much more reliable answer to...</comment>


What Happened to Hadoop - <AUTHOR> https://architecht.io/what-happened-to-hadoop-211aa52a297 <comment><USER2> I think Hadoop lead the big data space for a long time. It was just that better solutions like Spark arrived which sort of made us move from it. On another note, there are still remnants of Hadoop. My company still uses Hive for example.</comment>


A message for young people from a grumpy old man - <AUTHOR> https://medium.com/mid-life-survival-guide/a-message-for-young-people-from-a-grumpy-old-man-ac62dc72a3a4 <comment><USER2> Ya know... I am also a grumpy old man in my 40s. And when I started coding, I wanted to write software. I wanted to learn how to code, and get good enough at it to write something used around the world. The original dotcom boom came up. And I did it. I accomplished my career goals at the age of 28.

I did exactly what this articles recommends.

My friends, work has been boring ever since. Successful, stable, reliable. And boring.

So I looked around. I explored the world. I climbed mountains. I got married. I started a family. I practiced martial arts. I painted. I learned to make furniture. I explored every nook and cranny in my home state, then moved and started exploring another one.

In other words, sure... make some goals and complete then before you are 30. But then... make a 2nd list. Have goals for when you are young. Have other goals for when you are not. Have goals once you finish your goals. Go find a place in life that makes you happy, and if you are not in that place, move and keep exploring until you find it.

Because death doesn't begin at 30. It begins when you give up.

<comment><AUTHOR> Thanks for the great reply.

</comment></comment><comment><USER3> A message for a grumpy old man from another grumpy old man, I can't read your message if it's behind a third party pay wall.

<comment><AUTHOR> Here's the Friend Link: [https://medium.com/mid-life-survival-guide/a-message- for-you...](https://medium.com/mid-life-survival-guide/a-message-for-young- people-from-a-grumpy-old-man- ac62dc72a3a4?source=friends_link&sk=426c52a3902b3b3df78a9629a489b8e2)</comment></comment>


Ask HN: Plain text emails in 2017? - <AUTHOR> Hi, guys. From day to day, we send lots of emails and a huge fraction of those are of marketing nature. We're used to actionable HTML stuff in our inbox, and there are very few clients that don't support HTML email layouts. Still, we usually send two versions. HTML and plain text. Do we really need to send plain versions or it's just a second system syndrome of doing everything "right"? <comment><USER2> > Do we really need to send plain versions or it's just a second system > syndrome of doing everything "right"?

Yes, you do need to send plain versions. I make my e-mail clients to use plain text version first, and if that's not available, HTML version dumbed down to plain text. The cases when somebody needs to send formatted e-mail are really, really rare. Though...

> From day to day, we send lots of emails and a huge fraction of those are of > marketing nature.

...I delete marketing e-mails on the spot.

<comment><AUTHOR> Personally, I agree emails should be sent in two versions. However, there's a trend of sending just HTML. This article was written some time ago [https://litmus.com/blog/best-practices-for-plain-text- emails...](https://litmus.com/blog/best-practices-for-plain-text-emails-a- look-at-why-theyre-important) and latest comments will also promote the idea of dumping plain text.

Regarding marketing emails, I mean every automated email sequence. Like, you definitely get receipts and stuff over email. And those aren't written by hand.

<comment><USER2> Receipt or order confirmation _is not_ (or at least _should not be_ ) a marketing e-mail. It's a technicality necessary for transaction.

<comment><AUTHOR> However, the rule of thumb, especially for drip campaigns, is that you do get some marketing content with almost every email. This could be a specific sign off and such.

</comment></comment></comment></comment><comment><USER3> > Do we really need to send plain versions or it's just a second system > syndrome of doing everything "right"?

It depends on your costs / target ratio. You will have a percent of users that absolutely need to get text emails. If delivering text e-mails to them gets you more money than you spend sending the two versions, send them. Otherwise, just send the HTML ones.

Same for browser support. If, for example, you spend more supporting IE than you gain from only-IE users, just don't support IE.

<comment><USER4> I agree with the suggestion that you analyze how much of your sales are to customers who prefer plain text and assess whether it covers the cost of maintaining it. However, the numbers might not tell the whole story because some people deliberately block or ignore html mail even though they could figure out how to read it if they really wanted to. You probably don't monitor the replies to your marketing emails so you'll miss the replies requesting plain text format. (Nobody's going to look through your html code in their plain text mail reader to look for the url they have to copy and paste into a browser to access your web app that lets them change their email preferences to read your future marketing emails. They probably consider their time at least as valuable as yours.)</comment></comment>


Physicists track a quantum system's wanderings through quantum state space - <AUTHOR> http://news.wustl.edu/news/Pages/27133.aspx <comment><USER2> I believe this is the paper (letter) they're talking about:

[http://www.nature.com/nature/journal/v511/n7511/full/nature1...](http://www.nature.com/nature/journal/v511/n7511/full/nature13559.html)

and here's the version at arxiv.org:

[http://arxiv.org/abs/1403.4992](http://arxiv.org/abs/1403.4992)

Note the use of the Bloch sphere to represent the state space:

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

</comment><comment><USER3> fragment describing the gist of the experiment:

 _" The [entering] microwaves are so far off resonance with the [superconducting] circuit that they cannot drive it between its ground and its excited state. So instead of being absorbed, they leave the box bearing information about the quantum system in the form of a phase shift (the position of the troughs and peaks of the photons' wavefunctions)._

 _Although there is information about the quantum system in the exiting microwaves, it is only a small amount of information._

 _"Every time we nudge the system, something different happens," Murch said. "That's because the photons we use to measure the quantum system are quantum mechanical as well and exhibit quantum fluctuations. So it takes many of these measurements to distinguish the system's signal from the quantum fluctuations of the photons probing it." Or, as physicists put it, these are weak measurements. "_

</comment><comment><USER4> What happened to the old idea that when you observe a quantum system, its wavefunction collapses? Is that not true anymore? It seems like these guys observed it "gently" enough that it only sort of mostly collapsed with some bias?

<comment><USER5> According to the article, what they measured doesn't really sound like a 'real' quantum system: it's a superconducting circuit with two discrete states with an infinite number of previously immeasurable superposition states in between. They call this an 'artificial atom'. Unless I'm mistaken, it's an emulation of sorts.

[http://arxiv.org/abs/1202.1923](http://arxiv.org/abs/1202.1923)

<comment><USER6> It is absolutely a real quantum system. It's an artificial atom. It has basically approximately the same Hamiltonian as a trapped atom but at 6 GHz, and we can control the coupling.

</comment></comment></comment><comment><USER7> Couldn't they use this method to communicate over vast distances? I mean shit you could build a computer that uses something like this to measure the shift in a superimposed particle; this would allow communication to anywhere on earth without physical or wireless connection. All that's need is superimposed particles.

<comment><USER8> [https://en.wikipedia.org/wiki/No- communication_theorem](https://en.wikipedia.org/wiki/No-communication_theorem)</comment></comment>


Would you buy this C++ book? Please help shape its structure and contents - <AUTHOR> http://cdmh.co/12AO5dJ

<comment><USER3> Quite frankly, I don't understand why people write encyclopedia sized books for CS topics. Firstly, the relevant themes change very quickly. Second, nobody has the time to read a 1000 page book, where one topic just follows the other. Third, after reading the whole book one might realize -- oh how do I use lambda's in C++[1], a new feature introduced recently? If people are buying books to learn lambdas, your entire effort might be rejected because of one topic.

As authors we need to understand that aspiring programmers have the whole web, where easy to read blogs and article surface on a daily basis. Paper books are more of an impulse buy than a self-education commitment. Books are too monotonous and incomplete to compete with the web.

That said, I will be honest and say that I will not buy this book. I will just Google for topics, read a book like Learn * the Hard Way [2] or take one of the Coursera courses [3] to get started. I would encourage you to find new ways to delivering study materials (through video for instance) than just writing a book -- which I personally think is a disruption waiting to happen.

On the other hand, if you succeed in writing a book like [4], then things are different -- you are explaining programming and not a language (syntax, features and caveats).

Good luck!

      [1] http://en.cppreference.com/w/cpp/language/lambda
      [2] http://learnpythonthehardway.org/
      [3] https://www.coursera.org/course/cplusplus4c
      [4] http://mitpress.mit.edu/sicp/

<comment><USER4> agreed, most people don't take the time to read such books... that's one reason for the sorry state of the SW industry!

</comment></comment><comment><USER5> Paul Graham's _On Lisp_ doesn't talk about configuring Emacs. It sticks to the important ideas which are not widespread. It doesn't try to be a survey.

<http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf>

What I am suggesting is that a section on compiler warnings is just stamp collecting. The reader still needs to RTFM. Same with source control and development servers. At best these are items for an appendix or end notes. Don't drag the reader through context unless you are writing a textbook - <USER2> even then, don't.

I guess the tl;dr is that the table of contents looks longer than necessary for a book which has a thesis about design. Respect the fact that your readers will work out the implementation for themselves. Save "Use const wherever possible" for the supporting blog.

Edit away everything that is unnecessary, as I have not done with this comment. Do you really have something objectively important to say about namespaces, or are you just expressing an opinion based upon your preference? And even if you do have something important to say, about namespaces, is it something that a professional developer can integrate into their existing workflow without horrible disruption?

What is the MVB?

Good Luck

</comment><comment><USER6> Stack overflow talks a lot about its C++ FAQ tag. It may be good to include this information:

[http://meta.stackoverflow.com/questions/68647/setting-up- a-f...](http://meta.stackoverflow.com/questions/68647/setting-up-a-faq-for- the-c-tag)

<http://stackoverflow.com/tags/c%2b%2b-faq/info>

[http://stackoverflow.com/questions/388242/the-definitive- c-b...](http://stackoverflow.com/questions/388242/the-definitive-c-book-guide- and-list)

NOTE: I am not sure I would buy it, but I might read it!

</comment><comment><USER7> I wouldn't buy it.

I'm a C++ programmer with over 10 years, I buy software books, but I basically only go for well vetted books.

I dislike a chapter heading reading "Exception throwing destructors" even if that is a one page chapter with one big word "Don't." It also happens to be the type of thing I already expect a professional C++ programmer to know.

Actually, the only chapter I found interesting is #12 (MapReduce) and it doesn't really have much to do with reliable C++. But after reading up on this, I found that it gained little interest in boost [1], and its description in [2] is rather bland. Compare the description for N3554. So, instead, a book with only chapters like #12 but which touched on very useful, well-tested libraries would actually be more interesting. Not the normal libraries, the usual ones like boost in which professional programmers should already be adept, but some other ones that are real gems nonetheless. But all that is assuming that I would still be interested in writing C++ code.

However, I don't really see a future for C++ for most purposes, so "Scala for Profesional C++ Programmers" may be even more interesting.

      [1] http://lists.boost.org/Archives/boost/2009/08/155729.php
      [2] http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-part-2.html

</comment><comment><USER8> No, wouldn't buy it.

The beginning of Part 1 looks more like a beginner programming book than a C++ book. They're important topics, but none of them are specific to C++, and they're not the reason I'm buying a C++ book.

The rest of Part 1 looks like a rehash of "Code Complete" and "Clean Code." There are already good books on those subjects, and I'm not seeing what this one adds. Might be interesting to the same people who don't know about SCM and compiler warnings, but I'm not in that demographic, and even they are probably better off in the long run going with other books.

Part 2 looks interesting, but not enough to buy the first half of the book along with it. There are other books on writing reliable multi-process/multi- threaded code (both in general and in C++), and my impression is they would go into more depth than a book that tries to be as broad as this one.

I should point out I was already predisposed to say "no" because my preference is to avoid books that tie themselves to a specific language unless I'm learning the language or the particular language has an unusual advantage for a particular thing (such as Erlang for reliable multi-processing). Unfortunately neither of those apply here, so I'd prefer the more general books on these topics.

</comment><comment><USER9> First, I'll second brudger's point about scope. You say this is targeted at professional C++ developers, so you can assume a basic understanding of how C++ features work and restrict yourself to explaining how to choose and use those features to write reliable programs, don't feel any need for "completeness".

You've got two sections, guidelines and design ideas. I would probably get the most value out of the design ideas section, as learning new patterns to do things well is always handy.

But the guidelines section you're going to have to be a lot more careful. Most C++ advice books are targeted at beginners for a good reason, everyone has an opinion about how to write C++ best and they are rarely well supported. I would expect advice intended to be taken seriously by professionals to come with _specific_ real world examples of how it addressed a reliability problem in a largish project, not just an expert author's say-so.

If you could actually collect that, it would be incredibly useful. You could even give it a nice inflammatory title like " _n_ C++ mistakes that have wrecked projects"

<comment><USER5> Rereading my comment, I was going to add an edit about examples. PG's two Lisp books have non-trivial examples, among them PROLOG in Lisp and an inference engine. Seibel's _Practical Common Lisp_ also contains reasonable examples - though not as full blown as PG's.

My gut tells me that the Cpp book market is mature. Clojure is a language where one could combine the literary tradition of Lisp with the sobriety of the Java shop.

</comment></comment><comment><USER4> Sure.. It should reference Lakos for good design. In ch7, you should have a section about singletons. Singletons should not exist, GoF hurt the industry a lot by saying singleton was OK... it most certainly is not OK. No one needs it, and to get reentrant code you don't want it.

For ch9, it's like a C++ version of the Goetz book... you should make the same point: people shouldn't write their own thread pools. Also make a point about ownership transfer when posting to a pool: just don't share any data.

</comment><comment><USER10> Step 1: Put a basic book ToC onto the interwebs, and ask others to make it better.

Step 2: ???????????????????

Step 3: Profit $$$$$$$

like there aren't 100 Cpp books already available that would cover the topics in far more detail than this ever would.

</comment><comment><USER11> That the first sentence of your announcement of "Reliable C++" should contain an obvious typo is an unfortunate paradox.

<comment><USER7> Maybe it's not a typo. You can fill in the appropriate verb. ... plan to improve ... ... need to improve ... ... hope to improve ... ... forgot to improve ... ... don't intend to improve ... ... leave it to me to improve ...

<comment><USER11> :-) It's been corrected now.

</comment></comment></comment><comment><USER12> Your link that goes through two URL shorteners. It's tacky.

</comment><comment><USER13> Nope.</comment>