Bail us out, nerds. - <AUTHOR> http://indexed.blogspot.com/2008/04/bail-us-out-nerds.html

<comment><USER2> Ah, a very clear and concise appeal.

I just read <http://thebackofthenapkin.com/> on a train ride last week.

It's a good read about how to solve problems and sell ideas with simple pictures like the one in that post.

Not sure what I can add to the discussion about the topic in the image, but I was inspired to share the book.

And Seth Godin(Oh really? I hear he's on Internet.) says it makes you smarter, so maybe we can use it to fight the anti-intellectuals :D</comment>


Icahn Left Trump Victory Party to Bet $1B on Stocks - <AUTHOR> http://www.bloomberg.com/news/articles/2016-11-09/icahn-left-trump-victory-party-to-bet-1-billion-on-u-s-stocks <comment><USER2> My Filipino friends also all ran to the exchange today to stock up on low PHP since Trump presidency means no pressure on Duterte and rise of their peso.

</comment><comment><USER3> All of the futures markets were down around 8 pm on Election Night. I remember asking myself who might have shorted on futures.</comment>


SEOmoz raises 18 million from Ignition and Foundry - <AUTHOR> http://www.seomoz.org/blog/mozs-18-million-venture-financing-our-story-metrics-and-future#companytoday

<comment><USER2> This is great. In an ocean of depressingly terrible SEO information, advice and tools shrouded in secrecy by pompous quacks dressed in fake wizard robes SEOMoz has always stood out as completely open, ethical, high quality and useful.

I've also seen Rand talk and he's very passionate about what he does, I recommend anyone who gets the chance sees him speak. It's hard to not have his enthusiasm rub off on the audience and leave you re-motivated and full of ideas again.

There's definitely a huge market for this. Just look at how much absolute crud and misinformation there is out there. How many people are still being ripped off by SEO cowboys. I'd really like to see SEOMoz succeed and become more mainstream and well known.

I'd like to one day to hear small businesses asking about SEOMoz and other high quality companies/tools/sources of SEO information as supposed to going along with the first cold calling spammer that phones them up.

</comment><comment><USER3> Talk about taking transparency to the next level. This post has revenue, freemium conversion data, cap table breakdown, valuation, vc negotiation detail, and how Rand and his co-founder / mom amicably decided to part ways. Amazing. Has there ever been a private company at this scale with this level of transparency? Go SEOmoz.

</comment><comment><USER4> I'm very impressed with their openness and in describing the process. They share revenue projections, their cap table and pitch deck.

I'm also impressed with their non-standard move: They 'each sacrificed shares we owned to give back to each active employee at the company so they maintain their ownership percentage.'

They want to be a 'role model company in Seattle' and I truly hope companies follow in their footsteps in terms of openness and consideration for their employees.

</comment><comment><USER5> I love the transparency. You definitely get the feeling Rand would be an amazing person to work with.

I love that a funding announcement is so interesting that it will pull in tons of new customers.

</comment><comment><USER6> I paid 99$/month for few months, but I end up only using keywords tracking tool... 99$ was too much only for that feature.

Any saas offering only keywords tracking? For something like 9.99$/month?

<comment><USER7> If you're just looking for rank tracking, there's a few I've heard good things about (obviously, I like Moz, but I use a lot of the other features too, and am biased):

\- <http://www.advancedwebranking.com/> \- <http://www.gshiftlabs.com/> \- <http://authoritylabs.com/>

Hopefully those can help! And eventually, if you get deeper/broader in you marketing software needs, maybe we'll be worth another shot :-)

<comment><USER8> We have one as well (built from the ground up--my co-founder and I started building it in October 2010!)

<http://whooshtraffic.com/rank-tracker/>

Our rank tracker also has a competition analysis tool attached--so you can get data like # of backlinks, etc. for the top 10 Google results for any given keyword.

<comment><USER9> Co-founder weighing in here, for you HN geeks we use Erlang, RabbitMQ, and Riak for our rank tracker software.

</comment></comment></comment></comment><comment><USER10> Really great writeup. Congrats Rand and the whole team! I'm impressed the VCs were ok with Rand publishing so much data publicly. I hope more companies are this transparent with information...it really helps level the playing field for startups and entrepreneurs to have access to this kind of data.

Congrats again!

</comment><comment><USER11> Love it. Their software is pretty damn good, I hope they become the de facto SEO package and make scads of money.

Rand's writing about marketing and the inner machinations of growing a company are always worth reading.

</comment><comment><USER12> Not really an SEOmoz fan (nor do I have an opinion on them), but the insight into their deal was very welcome and it's good to see that they've got big plans.

<comment><USER13> I have been a paying customer for 6+ months, and I don't think they are the best service. But when open site explorer has recent data, it is extremely helpful.

</comment></comment><comment><USER14> Congrats to Rand and the SEOmoz team.

I can't wait until SEOmoz eventually re-brands to "Moz", dropping the "SEO" part of the equation.

</comment><comment><USER15> Rand is also pushing a HN for online marketing - <http://inbound.org/>

I hope it takes off, but the community behind it is currently non-existing.

</comment><comment><USER16> Now that they have their own backlink crawler their information is extremely valuable to any self respecting SEO. It's expensive, but that's probably because of lack of competition.

</comment><comment><USER17> mercenary, if you knew Rand at all, you'd realize how dumb such an insinuation sounds.

Also, Brad Feld is no dummy. He may not have the Midas Touch, but he doesn't buy into crap, either. I suspect we'll be hearing a lot from Moz in the future.

</comment><comment><USER18> Congrats Rand and team. Very well deserved.

</comment><comment><USER19> There's an infographic in one of the slides about the SEOMoz culture that I love and reminded me of the originating post that gives a solid overview:

[http://www.seomoz.org/blog/establishing-guiding- principles-a...](http://www.seomoz.org/blog/establishing-guiding-principles- at-seomoz)

</comment><comment><USER20> EDITION: stupid brainrashed children say "rite dis" i rite. i say rand good guy rand good. seomooooooooooooooz i buy. 99 cents onry. i buyyyyyyyyyyyyyy.

congo rats ulations rand seomoz good marqeteen jawb. sory end congrexuleeytions end have nice day.

<comment><USER21> They have built up a large social media following, possibly the best for a company of their size in a niche their size, with a lot of hard work and great content.

<comment><USER20> i rike dem to. i mean say why is cost a lot but people say 99 is cheap coz seomoz is best of da best onry. i use transrate stupid brainwash children say me write dis, did no mean. rand good guy i buy rand stufings.

<comment><USER22> I'm curious, how did you find Hacker News?</comment></comment></comment></comment>


Front-End Developer Handbook 2017 - <AUTHOR> https://www.gitbook.com/book/frontendmasters/front-end-handbook-2017/details <comment><USER2> I made a pretty sophisticated Angular app a few years ago which is still selling and being maintained by other devs on my team. I started helping my friend with a new app and realized I'm already obsolete. Screw frontend development, I'll come back when things settle down.

<comment><USER3> I have the feeling Angular was fad.

I met many people who bet on it, but most of them, even the 'fanboys' didn't seem to be 100% convinced of it.

"We panicked multiple times, bit it always turned out we were wrong and just didn't do things the Angular-Way"

Ember, for example, is kicking it for a much longer time, even with fewer ppl using it.

<comment><USER4> I am using Vue, which is much simpler than Angular. With Angular2, I spent a few weeks and still wasn't able to understand how things are working, contrast that with Vue, I was up and running within one week, migrated my html only app to use AJAX in a matter of a week!

[https://github.com/thewhitetulip/Tasks- vue](https://github.com/thewhitetulip/Tasks-vue)

Vue.JS is great to use!

<comment><USER3> Same with React. Tiny API, not much concepts.

Even Cycle.js just has a few concepts and is even more flexible than React or Vue.

Angular 1&2 feels like someone let loose a Java or C# dev onto JavaScript, who tried to apply all the design patterns™

<comment><USER4> I feel Vue is simpler and faster as far as programming is concerned as compared with React.

<comment><USER3> yes, it's more OOP like the others. which is probably easier to understand for most devs.

But I'm currently buying into the FP fad, haha

<comment><USER4> :-D I am not in any fad as such, but for some reason I find writing functions better than writing classes, it is faster and more intuitive to write vue-js code than react code. Simple architecture and small API.

<comment><USER5> Funny you should say that since the other person was implying that React apps are usually functional(largely when paired with Redux).

<comment><USER4> I was under the impression that functional programming and programming by writing functions are two different things.

Also, I might have said it incorrectly, the thing is, Vue has a clean API, you have to hook up lifecycle functions, so all I have to write is a Vue element with six lifecycle functions and one function each for distinct AJAX call.

Sorry for the confusion.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> It should be called Front-End Developer Handbook Early 2017. Or even early Feb 2017 ;)

Now seriously, how's the front-end progressing currently? Has the pace become a bit more humane?

<comment><USER7> > JavaScript will settle, and hopefully, CSS will erupt and everyone will cry > fatigue until it settles.

Sounds pretty accurate. My perception is that a large part of the JS community has started to settle on React with Redux/MobX for state management.. Facebook also really lowered the barrier to entry for React with create-react-app. CSS is still up in the air a little bit, with many different solutions still being used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components (which is very promising, but lacks features like universal rendering out of the box).

<comment><USER8> I think WebAssembly is really going to shake things up here in the next few years.

<comment><USER9> Why? Besides easy deployment (sometimes), what does it offer over desktop applications?

<comment><USER8> Over desktop applications? Ease of deployment, cloud based, etc. Most things have already moved to the web anyway, so it's not really a competitor against desktop applications, it's a competitor to everything that is already in the web.

<comment><USER3> As far as I know it's not suited as target for many mainstream languages.

It's more like the NDK in Android. So ppl can write high performance libs in non-gc languages like C or Rust.

</comment></comment></comment></comment></comment></comment><comment><USER10> I'd argue that front end development tools are complex and varied because the craft itself is complex and varied. Try to strike the optimal balance between usability and fine control. It's not easy. How to welcome newbie developers with intuitive tools while not frustrating experienced ones with blunt instruments. Imagine all the schools of thought for how to best achieve this delicate balance. Not to mention beauty and elegance in design.

<comment><USER11> Front-end is not fundamentally complex at all, the only complexity comes from ever changing tools and techniques. I occasionally create websites (approx. one or two per year) for my own or family/friends use and _every_ time I have to learn everything anew, because the tools I used a year or even several months back are no longer around or have changed beyond recognition.

</comment></comment><comment><USER12> Just take information there with a grain of salt. The what to expect in 2017 section says that web components will never gain traction where in fact one of the biggest enterprises in their industries adopted them already: Github, Slack, Comcast, USAToday (Ganett), ING, Coca-Cola, Electronic Arts, General Electric, Google, Youtube and others.

Just [https://www.webcomponents.org/](https://www.webcomponents.org/) reached over 500 reusable elements, just polymer slack channel is now 6,5k users.

The current growth and adoption looks very bright, chrome, opera and safari already shipped 1.0 versions of most of the spec (so no polyfills are needed), firefox is close behind and edge is implementing right now.

If this is not traction then I'm not sure what is. I'm not even accounting for other libraries/frameworks like x-tags, bosonic, svelte and others.

<comment><USER13> Have you used Web Components as part of a large project? What has your experience been?

I'd love to start pushing them to my clients, especially non-tech companies who can't afford to rewrite all their code every time a new framework becomes the fad, but I'm still kinda unconvinced. I'd love to read some real-world case studies.

<comment><USER12> Well if you want "big" cases you have Google Play Music, Youtube (gaming site, + the main one is being rewritten right now - you can force beta with some cookies), electronic arts sites like battlefield1 and others. Watch polymer summit streams they show some really high profile sites that use webcomponents.

Personally I've introduced web components using polymer library in two ways - upgrading legacy jquery based application and when starting a fresh CMS system with admin panel that is 100% SPA built with polymer (kind of like weebly interface - its not public yet).

It worked well for both of my cases, It felt quite similar to my previous angular 1.5+ component based approach (so I suppose it would be comparable to react/vue development).

Right now you can use polymer-redux or polymer-uniflow if you want to structure big application data flows.

I haven't encountered bigger obstacles or problems compared to other solutions I've used in the past.

I've integrated 3rd party libs like crossroads-router or quill editor just fine.

I looked a bit at Angular 2.x but for me Polymer look way more natural in terms in how applications should be build on the web.

What I did miss was a routing element like angular's ui-router (I didn't like `app-route` element)- but this is currently being worked on and there is a POC ui-router port for Polymer already.

<comment><USER13> Thank you so much for your response. I had no idea all those properties were built with Web Components/Polymer! Maybe I'm living in a React/Vue bubble, because this stuff has never shown up on my radar.

> I looked a bit at Angular 2.x but for me Polymer look way more natural in > terms in how applications should be build on the web.

Completely agree. In the long term, I'd love to see most reusable UI components on the web built with Web Components, with optional wrappers for people who still want to use frameworks.

One more question: is there currently a way to do server-side rendering for an SPA built with Web Components? I'm assuming something like jsdom will work?

<comment><USER12> No as far as I can tell this is not possible - because web components with shadow dom do not leak implementation details.

For example you have <video> tag - it has its own internal controls that are not part of the markup - same with web components - <my-custom-elem> is what the browser sees - not what is inside - for it it is just a DOM element.

Then again I haven't explored the subject too deeply since I do Python server side so js rendering is not an option here. I suppose it would be possible if you would drop the shadow dom from your elements.

</comment></comment></comment></comment></comment><comment><USER14> This link will get you to the handbook content: [https://github.com/FrontendMasters/front-end- handbook-2017/b...](https://github.com/FrontendMasters/front-end- handbook-2017/blob/master/SUMMARY.md)

</comment><comment><USER15> It's rather ironic that the front-end developer handbook doesn't support mobile devices.

Doesn't inspire confidence.

<comment><USER16> There is mention of mobile devices as early as page 8. There are 31 uses of the word "mobile" in the document. The document does not tell you how to build a website, it tells you about the tools you can use to do so reading as a series of lists linking to those technologies and a series of graphs. If you want to know about media queries for example, you have to follow the links. It's not meant as a PDF version MDN or W3schools.

edit: not usually one to complain about downvotes, but the document is literally what I described it to be. So, why?

<comment><USER17> I think you have been downvoted because you missed the point of the parent comment. The HTML version of the handbook is not readable on mobile (the table of contents leaves no room for the content).

<comment><USER16> Well thanks for telling me at least. I reread OP's comment and I see what was meant now, it wasn't clear to me at the time I commented though.

</comment></comment></comment></comment><comment><USER18> I did LAMP+HTML+JS+CSS stuff back in the day, but most of my work and hobbies over the past six years has not involved front-end. I only recently got back into the scene. I've dabbled with React and crew in quite a few hobby projects now and, at this point, I just find the whole modern front-end development stack completely wacky.

I always liked Javascript as a language, but like everyone else had the scars to show for its thorny bits. Looking at the modern stack from afar left me fantasizing about all the painful points in Javascript being fixed. ES20XX, Babel, webpack, npm. Wow!

To be honest, a lot of the modern stack _is_ nice. But for every step forward these tools take, they take two steps back.

We have a nice package manager, npm, yay, but what happens when I `npm install -S bootstrap`? Nothing. Oh sure, it installs it, but how do I _use_ it? It's tossed in node_modules, where there's no sane way to reference it. I ran into this problem immediately, on my very first hobby project. It's now two years later, 2017, and it's still a problem that requires googling around, sifting through old answers, and finding the hack that I find least painful.

Breaking up libraries into manageable sub-packages. Sounds great. It's fundamental to strong development. But usually you have a master application/library that references all the pieces, if the pieces were meant to be part of a coherent whole. But front-end devs? _shrugs_ You just have to include everything by hand. Has seriously no one looked at their package.json in a simple TODO app and said "Something is wrong here"? How is a 20-30 line list of dependencies normal for the most basic of applications? It isn't. It's isn't maintainable. No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago.

Fancy new JS language features are nice. `for of`, `for in`, filter, map, etc. But seriously I can't use `<SomeThing onClick={this.handleClick}/>`? I have to use binding magic, special function definitions, etc? Because _nobody_ has to register event handlers, right? Geez. And why did they spec a standard for classes, finally, but not static methods and types!? That had to come in another version later, leaving yet another legacy of out-dated documentation?

Webpack, like everything else, is an improvement by the numbers. Writing modular javascript and getting it packed into a bundle is nice. Almost like a real programming language! But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done. Break that one tool into sub-libraries/sub- tools underneath, I don't care, but when I'm building fancy Uber-for- breastmilk Web 2.0 SPA, I'd rather focus on UX than spending my evening configuring compilers to what should be their defaults.

The most frustrating thing, and a common theme, is the amount of times I need to Google things while developing with the modern stack. "Oh, ummm ... how do I export/import?" "How did I configure webpack last time?" "Errr ... how do you include a bootstrap theme?" "Was it `in` or `of` to iterate over values...?" "How do you filter in place? Oh, you can't ... okay..." A lot of that sounds like basic stuff, like "How do I export/import", but ya know what? The way it's implemented in modern JS is just not intuitive. Call me dumb if you want, but I've dealt with a _lot_ of languages in my time, and JS is the one where I cannot possibly remember the exact magical incantations for specific kinds of exporting and importing. And really, that's how everything is. It's just cryptic and non-intuitive. The underlying concepts of any of these major tools or systems is sound. The implementations are gibberish.

As much as I'd like to say "sorry for the rant", I'm not. Something is horribly wrong with developer culture if this abomination is what we've created. There's no excuse for it. I've heard people argue that all of this is just a result of front-end being in-between stages of its life, and that things will eventually settle down and be stable and usable in a few years. But you know what? Rust, a completely new and modern programming language, went from nothing to a thriving ecosystem in just a matter of years. It was driven by Mozilla, hardly the largest company. Meanwhile MASSIVE companies like Facebook, Google, Amazon, etc have given us the "modern front-end". There's no excuse for the ecosystem to be in this state.

"But you don't have to use all those libraries and tools!" Of course not. I could just LAMP+HTML+JS+CSS it up like the good ole days. It worked then, it works now. But it frustrates me that there exists tools that _should_ be better. npm _should_ make life easier. ES2017 _should_ make Javascript a better language. I tried out these tools for a reason. Old school development was painful. Javascript with modules and packages, reactive UI, state management, etc. It's all awesome! I'm not messing about with the tools for no reason.

Imagine if I sold you an automated potato peeler. "It'll peel the potatoes for you in seconds!" And it does! But turns out you spend more time cleaning it than you spent just peeling potatoes the old fashioned way. That's what the modern front-end tools are like. They take the painful parts of old-school front-end and make them easier, but they add tons of busy-work elsewhere that ends up making things a net negative.

<comment><USER19> > But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?

Give a try to Vue.js, you can do exactly this. This framework reconciled me with frontend development after I discovered it on HN. Let's say you want to build a custom button with a special functionality and reuse it, like a button that logs when it has been clicked. Simply create a component like this (it's almost self-explanatory):

        <template>

{{ text }}

        </template>

There are 3 sections in the file, one for the HTML template, one for Javascript code, one for CSS style. All this belongs to the same components, so the methods you defined in the javascript code can be called directly from the html template as you wanted.

Once your component is ready, you can use it in other files, and in a damn simple way:

        <LogButton text="Delete" @click="…" />

<comment><USER20> I _really_ like Vue, and I _love_ single file components.

React folks: Is there no way to do this with React? I may need to use React soon, and if it can't do this I'm going to be pretty sad.

<comment><USER21> You can write components however you want. For components and styles, there's numerous approaches, and it's up to you which one you use. You can write your CSS totally separately, you can import CSS into a JS file and have it auto- generate unique class names, you can define styles completely inline in a component, and so on.

Can you maybe clarify what you think you can't do with React?

</comment></comment></comment></comment><comment><USER22> As a junior dev, that list almost makes me want to run to the hills...where I will presumably stumble upon another similarly monster-like list telling me all the things I need to learn to become [insert job role here].

<comment><USER23> Hint: Move to the backend. Building the APIs that crunch SQL into JSON for the react/angular/fad of the week folks to consume is much easier, and the half- life of your framework and language knowledge can be measured in years, not months.

<comment><USER24> Alternatively, find somewhere to work that doesn't insist on using the latest 'greatest' new fangled bollocks technology simply because it exists.

<comment><USER25> This is a double-edged sword, though, as it may hurt you once you try to switch jobs again.

</comment></comment></comment></comment><comment><USER26> It's a nice little book. Normally these things can be a bit hit and miss with the way the authors opinion of code structure seeps into them. You often end up with a bit of a 'this is wrong' mentality when in fact there is nothing wrong at all - thankfully they seem to of avoided that with this one.

</comment><comment><USER27> I wish there was something similar on Backend development, or better, full- stack development.

</comment><comment><USER8> Are full-stack developers really as rare as the book says?

<comment><USER3> Back in the JSP/ASP/PHP days, everyone was basically a full-stack dev. Because of server side rendering and direct DB access etc. I'd guess people who have more than 5 years of experience come from that direction.

So they aren't that rare.

But doing just one thing is easier.

When I do back end stuff, I have to think about scalability and API design, which is hard enough in it self.

When I do front end stuff, I have to think about information architecture and perceived performance.

I can do both, but I don't have infinite time, so I focus on the things I like the most, which is the front end :)

<comment><USER28> A lot of the people I knew doing "full-stack" (which just wasn't a phrase back then) 5-10 years ago basically were still much stronger on one side than the other. I knew a whole bunch of guys who could build you a beautiful - for the time! - Flash site _and_ they could store data via PHP into a MySQL database _and_ they could deploy it on a server ( _and_ then they could send you an invoice! Seriously, totally full-stack)... but my goodness would you not want to look too hard at the PHP, because little Bobby Tables would have cried.

<comment><USER3> This is true, but doesn't help in the discussion.

There are always people who are good at something and bad at something different.

</comment></comment></comment></comment><comment><USER29> I see people everywhere complaining about how frontend development is moving too fast, and stories like mrits.

In 2011 I was sales manager in Mexico, doing WordPress sites for free on the side just for fun. In 2012 I migrated to the US with my family (legally). Then I worked in maintenance for 6 months until they fired me because I couldn't talk English.

After that I decided to try to live from building websites. I started to learn JavaScript and CSS, because already knew some HTML.

So I landed some clients as freelancer doing fixes on old sites, updating WordPress. When I landed my first WordPress site from scratch I didn't know how to do it, so I bought a book on the topic and used the gig as practice while reading the book.

I was able to maintain my family doing responsive WordPress sites. Then I started to get issues with all the grid frameworks and stuff, it was too complicated to make a simple website responsive.

So I started to do what everyone tells you not to do: "don't reinvent the wheel". I got myself to build my own grid, I did it, and I still use it Today. The process was painful because I didn't knew any real CSS so forced myself to learn it, when I got it done I was very confident I could do any layout in CSS.

One freelance gig I got was a SEO tool to count the amount of words, paragraphs, syllables, etc. of a given text, it was really exiting, because I knew I had to learn JavaScript to do it. At that time Backbone was really complicated for me, so I did it but really mostly copy/pasting stuff, I was happy with the result but not with the methodology. One thing I really learned from this project, is how to setup my development environment with Grunt.

So at this point I knew enough CSS and how to setup task runners.

From 2013 to 2015 I did only freelance work, then I got a full-time job at a small advertising agency, doing WordPress sites.

I was able to get my paycheck doing stuff that wasn't complicated for me, get a PSD, make it a responsive WordPress site (with the grid I did) and done. So I was able to learn JavaScript on my free time, so I did what worked for me in CSS again, go a reinvent the wheel.

I did my own "Backbone"-like framework, and was able to learn about Object- oriented programming and how to do it in JavaScript using prototype inheritance. Then I found out about React, and started using it too, learned about functional programming, pure functions, immutable data, declarative syntax.

At this point I was using Gulp, Sass, Babel, NPM, learned how to use the command line too, Vim, Tmux, was using Linux as my primary OS, and other very cool tools.

So in 2016 I landed an interview for a company where the job title was frontend developer, so for me was like no more "make my logo bigger" website clients. I got the job, Today I do only JavaScript using React/Redux/React- Router, I learned Vue.js on the side and learned Python too, so now I can do my own backend using Bottle/Flask on my freetime, learned about MongoDB, Postres, SQLite.

And these days I'm building my own virtual dom implementation to understand better how it works. And yes, a new JavaScript framework gets released everyday, and yet I try to use as many as I can, spend a couple hours building a todo app, reading the source code to see what I can learn from it, etc.

Right now I'm loving preact, and couple days ago found out [https://github.com/hyperapp/hyperapp](https://github.com/hyperapp/hyperapp) which is really cool.

The point of my boring story is:

\- frontend development moves fast, get with it. Don't expect to learn something and keep using the same shit for ever.

\- learn JavaScript, not frameworks. If you understand the language you are going to be able to understand any framework better

\- if you want to learn, reinvent the wheel

\- avoid the hype

\- if you are freelance and need to make a simple app and you are comfortable with jQuery, go fucking do it in jQuery and don't mind about the new cool stuff yet.

\- Backbone, Angular, Ember, React, Vue, or Preact? Whatever, when I open the source code of a project built on any of those frameworks I only see JavaScript patterns, that's it.

If you get a job and they are using something you don't like or something you don't know, read the documentation, learn the basic idioms and try it. Again, at the end, it's just JavaScript.

I mean, I was 29 when I started my journey, no English, no CSS, no JavaScript, no knowledge about software development good practices. Now I'm 33 and very happy with my job as frontend lead developer.

<comment><USER30> Excellent history and good advice :)

</comment></comment><comment><USER31> The current front-end web stack today is not the answer, I think that is not so controversial except to the most die-hard fanboys. Most of the contents in this handbook are going to be worthless in a year.

Most front-end work is repetitive, with some minor variations. Rather than a framework, I think that perhaps an expert system for making web apps that is basically an interface for metaprogramming, would be a vast improvement over the current tech.

<comment> shaki-dora Let's see, going by the index, which technologies are younger than a year (the logic being "would your statement have made sense a year ago" because I obviously can't prove if a technology will still be relevant a year from now):

Internet/web: no

Web browsers: no

DNS: no

HTTP: no

Web Hosting: no

UI Design: no

HTML: no

CSS: no

SEO: no

JavaScript: no

DOM, BOM, JQuery: no

Web Fonts: no

Accessibility: no

... and so on. But maybe you meant just Javascript libraries, which seem to make up just a small part of the content, but ok... Let's use "Module/Package Loading Tools" as a sample, because this thing is really to big to go through everything:

Browserify: Started in 2012. So... nope

Rollup: Started in 2015. No (but close!)

SystemJS: 2013. Nope, sorry

Webpack: 2013. Nope

And let's arbitrarily add the behemoth:

React: 2013. Nope

It appears there was an awful lot of new frameworks in 2013 and that let to the impression of framework churn. To perpetuate that narrative four years later seems to be more groupthink than reality.

<comment><USER32> What people are feeling as "framework churn" is probably more like framework uncertainty.</comment></comment></comment>


PMA Illinois Lawsuit Victory Upheld - <AUTHOR> http://thepma.org/pma-illinois-lawsuit-victory-upheld/ <comment><AUTHOR> (In reference to PG's earlier post about titles, I left the original)

The affiliate nexus tax was challenged in Illinois by the PMA and was struck down. However, the state appealed and the result of the appeal is that the original decision stuck. This is very good news for affiliates everywhere as it makes the likelihood of such legislation passing - or surviving - <USER2> slim.</comment>


Non responsive design - <AUTHOR> http://www.welcomebrand.co.uk/thoughts/non-responsive/

<comment><USER2> It is kind of funny how responsive design has become perceived as a silver bullet for web design. There are still situations where a traditional m.domain.com approach is better.

Responsive is great if your site is mainly concerned with serving up content, like a news site or blog. But if your mobile users have significantly different use cases than your desktop users (as is sometimes the case with applications), it may make sense to serve up a separate app entirely.

Not to mention that it's still really hard to optimize responsive to the point where it performs as well on mobile as m.domain.com sites</comment>


Zed Shaw: The wonderful Rob Sobers did a great job translating LPTHW to Ruby - <AUTHOR> http://ruby.learncodethehardway.org/ <comment><USER2> I started off doing this to teach myself Ruby. I enjoyed the Python version so much and thought it would map pretty well since the languages are fairly similar.

After about 15 exercises, I saw that it was actually coming out quite nicely and reached out to Zed. Zed was super cool about releasing it under his license as long as the end result was high quality.

I wouldn't have cared if he said not to release it because I got to learn Ruby and play with Sinatra, Jekyll, etc.

<comment><USER3> I've been working on corrections and I was actually struck by how seemingly trivial differences in the languages can completely break large parts of the book. For example, the python version introduces modules fairly early because they are needed for other lessons. But I don't think there is a single library dependency in the entire Ruby version. It can't introduce require and then never use it, but there is very little entry level stuff in the Ruby standard library. There should probably be a chapter on making your own libraries, but that would have to be new material very late in the book.

<comment><USER2> Huh? require is used quite a bit: exercises 12, 25, 43, 47, 48, 50, 52. Some exercises depend on sinatra, some depend on test/unit, some depend on stuff you write yourself.

<comment><USER3> The problem is it's teaching you Python's module system, which is very different from Ruby's require system.

Ex. 12 introduces `require` with example code that is way over the reader's head at this point in the book, and unrelated to anything they have seen or will see until ex. 25. It also says that features are called "modules" but that's completely wrong -- Ruby modules are something else entirely. And the term "module" is used in the Python sense all over the book. All those need to be changed.

Ex. 25 asks the reader to require their own file but never explains how to get the file in the load path, so I don't think the reader has much chance of completing this exercise.

My point is that I don't think a direct per-exercise translation is going to work. Requires in Ruby are more complicated and used less often than modules in Python, and the book is very linear, so I think require will have to be introduced in a completely different way if it's going to make any sense.

There are other topics that have this problem, like heredocs. In Python they are pretty so it's ok to throw them at the reader early on. But Ruby heredocs will melt their eyeballs out of their sockets, and they are rarely used in practice, so they probably shouldn't be in the book at all.

I am working on these sorts of changes with the intention of sharing them with you to see what you think, but it's starting to snowball so I don't want to promise anything. I'll do my best.

</comment></comment></comment></comment><comment><USER4> There was an unapproved translation before, IIRC. I guess this is out because the adapter asked Zed's permission first and kept the copyright?

If so, I'm cool with that. Zed can be a firestarter, but this shows he's cool with others contributing something provided they do it the right way.

<comment><USER5> This is probably another unapproved translation as zed said his book was meant for teaching python and we need substantial changes for ruby.

The other book basically translated the code from python to ruby while keeping much of the text the same I don't know if this is the case with this one.

<comment><USER4> It's approved - check the domain (same as LPTHW)

<comment><USER6> <http://twitter.com/#!/zedshaw/status/99153296811507712>

</comment></comment></comment></comment><comment><USER7> (side note, there seems to be a page linking problem)

Clicking into <http://ruby.learncodethehardway.org/intro.html> and hitting the title takes me here <http://learncodethehardway.org/ruby/>

Clicking a link there takes me to <http://learncodethehardway.org/ex00.html>

It looks like that header should link back to <http://ruby.learnruby> ...

<comment><USER8> Fixed. I had to move it to ruby.lcthw.org to keep the various languages straight, but I didn't update the jekyll _config.yml.

</comment></comment><comment><USER9> Is there a single-page version of this available that I could put into my Kindle? Alternately, I'd be quite happy to pay for a copy if it was posted to Kindle Self-Publishing (<https://kdp.amazon.com>)

<comment><USER10> I wanted one too, so I PDF-printed all the pages, combined them into one file and also made a Kindle version: <http://bit.ly/o7gfMH>

It's hosted on Rapidshare. I expect Zed will have a better version soon, but this works in a pinch.

</comment></comment><comment><USER11> I work with Rob. I always knew he was awesome, but I didn't realize he was _this_ awesome. Great job Rob!

</comment><comment><USER12> Is there a particular reason pagination navigation is not used (e.g. at the bottom of each page, including previous/next links)?

<comment><USER2> No particular reason. I'll probably add this at some point since it's pretty helpful.

</comment></comment><comment><USER13> I was kind of bummed before that a book with such wonderful reviews was only available in one language. This is awesome! Thank you guys so much for doing this :)!

</comment><comment><USER14> Out of curiosity, is Rob Sobers pretty known in the programming community?

I have never heard of him before, but based on the way Zed wrote about him, seems that he just might be famous and I haven't heard about him (which is very possible).

Otherwise, if he was just a 'regular' web designer that learned Python the Hard Way and translated to Ruby and Zed has given him so much credit....that would be AWESOME.

In all honesty, quite uncharacteristic of Zed - as far as I know, not being a dick (just honest) - which is why I think he is 'programming famous'.

I am hoping he was just a regular 'joe blow' though.

Anyone know?

<comment><USER2> I'm definitely not "programming famous." My boss, Joel Spolsky, is though (I work for Fog Creek Software).

I don't know Zed personally either. He was a bit skeptical about me doing this at first, but he was ultimately really cool about it because I respected his terms, and if at any time he told me to ditch the book, I would have.

</comment></comment><comment><USER15> Could someone explain the reason why the "learn x the hard way" method has been so popular around here? I keep seeing the name thrown around, but haven't had a chance to look into it yet.

<comment><USER16> The reason is Zed Shaw. He has a large following here on HN.

<comment><USER17> And it's a pretty decent way to learn some basic programming skills, irrelevant of the actual language.

</comment></comment></comment><comment><USER18> I really like the idea behind these books, it reminds me of how I learnt originally, typing BASIC programs into my zx spectrum from the back of computer magazines.

<comment><USER19> I typed in CBM64 programs - not sure how helpful it was in learning to code though...

      2000 DATA 103, 20, 122, 58, 53, 240, 188, 86, ...

[ctd for 8 pages]...

<comment><USER18> i'm sure it was helpful. the first skill in learning how to code is little details, like making sure all the text is the same as the listing, and that you pressed enter after every line ... ;-)

</comment></comment></comment><comment><USER20> Where is the source for the quote from Zed Shaw? The link doesn't mention it at all.

I know Zed Shaw railed on a previous translation to Ruby; I'd be curious to know the backstory here about why this one is different.

edit: Nevermind, in a different HN thread[1] Zed talks about it.

[1] <http://news.ycombinator.com/item?id=2846671>

<comment><USER8> Zed here, this one is different because Rob asked permission and then did a great job actually completing the translation. It's not totally idiomatic Ruby, but it should be a good start for people.

<comment><USER21> I loved Learning Python the Hard Way so I think I'll do the Ruby version as well, would you recommend anything specific after it to learn idiomatic Ruby?

<comment><USER8> I am not sure, but I'll ask some Ruby folks who might know and then update the book to point people in the right direction.

<comment><USER22> The title _Eloquent Ruby_ has been getting excellent reviews by beginners and Rubyists alike. And I happened to have loved reading it.

It is basically a book of best practices and ruby idioms. (For example, the use of a ruby object's each method instead of for..in.)

</comment></comment></comment></comment></comment><comment><USER23> This is a great resource. I'm in the process of learning Ruby, and will be trying out Ruby Koans and Satish Talim's Ruby Learning site as well in comparison. Does anyone know how good those tutorials are, or if there are any other good online Ruby guides?

</comment><comment><USER24> @zedshaw Would you be up for a Factor version done with the same spirit and quality?

</comment><comment><USER25> Exercise 9:

10 There's something going on here. 11 With the three double-quotes

\- no triple-double-quotes in ruby version, actually

</comment><comment><USER26> I would buy it for Kindle!

<comment><USER27> Yeah, I would too.

But Zed, please check the Kindle version before you approve it. The Python book for Kindle is absolutely horrible - with all the code stripped out.

</comment></comment><comment><USER28> Great thanks Rob!

</comment><comment><USER29> It would be nice to be able to copy and paste the code snippets without the line numbers. Otherwise great job!

<comment><USER2> The point of The Hard Way methodology is to type everything out and understand what you're doing.

Having said that, you could clone the git repository, remove the "linenos" option and run the Jekyll site locally.

<comment><USER30> Regarding copy/pasting, I do agree. Not much of a point in reading if you're just going to do that.

But, I was having a problem with exercise 4 and so copy/pasted it from the webpage (removed line numbers with TextMate's vertical selection easily enough). Received the same error when trying to run it as I did when I typed it myself:

ex4.rb:10:in `+': can't convert Fixnum into String (TypeError) from ex4.rb:10:in `<main>'

I'm not familiar enough with Ruby to understand why it's doing that... my googling shows similar ruby tutorials with that format, but one site I found suggested using #{variable_name} instead of the " + variable_name + " and that worked just fine for me.

Is this a real error in the book or something weird going on with my computer (OS X Lion w/ Ruby 1.9.2 installed)?

Great book, by the way.

<comment><USER31> Couldn't get your way to work, it blew off the rest of the string. Managed to get it to work by calling .to_s on each variable. Wondering if I did something wrong. I have your same setup and I'm a complete Ruby Noob.

<comment><USER30> to be clear, my line 10 looks like this:

puts "There are #{cars} cars available."

But, yeah, complete Ruby noob here as well so I don't really know what's wrong.

<comment><USER32> >10 puts "There are " + cars + " cars available."

Yes, this will throw an error in Ruby because of line 1:

>1 cars = 100

Ruby does not allow the mixing of integers and strings. So, as mentioned, you can invoke the .to_s method. Or you can interpolate the variables as you have done so with #{cars} inside double quotes.

<comment><USER30> Thank you, that makes sense.

<comment><USER33> Interpolation actually calls #to_s on the object, so if object.respond_to?(:to_s) returns true, you can use use it inside #{} in any kind of string that allows interpolation.</comment></comment></comment></comment></comment></comment></comment></comment>


Pioneers - The latest initiative from the visionaries behind Thinkspace. - <AUTHOR> http://thinkspace.co.uk/pioneers Providing some of the world's brightest young entrepreneurs with more opportunities than they could get in a lifetime. <comment><USER2> This is an amazing project</comment>


Rare photographs that changed lives - <AUTHOR> http://www.bbc.co.uk/news/in-pictures-43031764 <comment><USER2> Go all the way down. The last photo is one of the most impressive. Children working with "guards" ready to beat them with a truncheon.

<comment><USER3> Is that really what's going on in that picture?

<comment><USER4> Well, on the one hand, I doubt they were using the threat of violence to get them to work. On the other hand, they were probably watching out for theft, and I have little doubt that they would have administered a beating if they caught someone pocketing coal.

<comment><USER5> As a little girl during the Great Depression, my grandmother and her friends used to throw rocks at the engineers on trains, to provoke them into throwing pieces of coal back at them. They'd then take the coal home for warmth.

<comment><USER6> That seems like a ton of effort. I know coal burns well but is it really worth that kind of effort in that quantity? (This isn't scrutinizing I'm just curious if this was a practice that was fruitful or if it was just kids thinking they were helping or something?)

<comment><USER5> Sadly, I don't know (or remember) any more of the story than that, and she's not around anymore to ask... It doesn't seem likely that they would have gotten huge amounts of coal by doing it.

</comment></comment></comment></comment></comment></comment><comment><USER7> That first photo reminds me of the Gotham Public Works logo from the Batman universe: [https://1.bp.blogspot.com/-L_2Oqwk1Gqs/TcauyYazjaI/AAAAAAAAA...](https://1.bp.blogspot.com/-L_2Oqwk1Gqs/TcauyYazjaI/AAAAAAAAAKo/zvTFtVSrLlI/s400/gotham%2Bpublic%2Bworks%2Bpinball%2Btopper.jpg)

I wonder if it was, perhaps, inspired by this famous photo?

<comment><USER8> Or by this monument?

[http://3.bp.blogspot.com/-KZvDYmzdiLQ/VetenUM0abI/AAAAAAABg0...](http://3.bp.blogspot.com/-KZvDYmzdiLQ/VetenUM0abI/AAAAAAABg0g/rBps6UbAyKo/s1600/IMG_7269.JPG)

Or by this Superman picture?

[http://4.bp.blogspot.com/-OhVeTMXYR9E/ThNZis3eEjI/AAAAAAAAAB...](http://4.bp.blogspot.com/-OhVeTMXYR9E/ThNZis3eEjI/AAAAAAAAABc/4PTSdagK4Rk/s1600/superman- in-the-heart-of-the-sun.jpg)

More seriously it is a kind of iconography that was present in many countries in the 1900-1950 period (and even later in URSS and other communist countries) often in the form of propaganda posters, here is a Chinese one:

[http://magazine.utoronto.ca/leading-edge/labour-days- chinese...](http://magazine.utoronto.ca/leading-edge/labour-days-chinese- propaganda-posters-elizabeth-parke-scott-anderson/)

[http://magazine.utoronto.ca/wp-content/gallery/chinese- propa...](http://magazine.utoronto.ca/wp-content/gallery/chinese-propaganda- posters/f6199.jpg)

Here you can see how another of Hine's photos (the one with the guy on the crane hook) has been used iconographically (maybe):

[https://wolfsonianfiulibrary.wordpress.com/2015/04/18/overt-...](https://wolfsonianfiulibrary.wordpress.com/2015/04/18/overt- covert-miami-dade-college-students-use-wolfsonian-art-objects-to-decode-the- iconography-of-labor/)

Hugo Gellert and William Gropper are good examples of (US) artists that did similar drawing/paintings:

[https://commons.wikimedia.org/wiki/File:William_Gropper_- _Co...](https://commons.wikimedia.org/wiki/File:William_Gropper_- _Construction_of_a_Dam_1939.jpg)

</comment></comment><comment><USER9> For those interested, the Library of Congress has a substantial number of Lewis Hine photos available online.

[https://www.loc.gov/photos/?fa=contributor:hine,+lewis+wicke...](https://www.loc.gov/photos/?fa=contributor:hine,+lewis+wickes%7Caccess- restricted:false)

</comment><comment><USER10> Oof. The "good ol' days".

<comment><USER11> Could you elaborate? Presumably, that's a sarcastic "the good ol' days before child labour laws".

<comment><USER10> The whole trope of romanticizing the past... you know... Make America Great... Again? As if it isn't, but it... was?

</comment></comment></comment><comment><USER12> On an unrelated note: why does nobody ever scale photos for viewport height? I can never see whole portrait-oriented photos without zooming out.

</comment><comment><USER13> in the last photo w/ the coal breakers... does that dude have a sword???

<comment><USER14> Looks like a stick to me, still gruesome. Btw. i found some more pictures from those "Breaker Boys" at work, check this out.

[https://i.pinimg.com/564x/25/40/25/254025955197cd827816dd9ac...](https://i.pinimg.com/564x/25/40/25/254025955197cd827816dd9acdedde60.jpg)

[https://www.mininghistoryassociation.org/Meetings/Scranton/B...](https://www.mininghistoryassociation.org/Meetings/Scranton/Breaker%20Boys%202%20USBM.jpg)

Identical Photos it seems, but one is retouched to remove the beating stick from the guards hands.

Very telling.</comment></comment>


Tcl the Misunderstood (not too new) - <AUTHOR> http://antirez.com/articoli/tclmisunderstood.html

<comment><USER2> True John Ousterhout (creator of Tcl) story.

I worked for John for many years, but our first meeting (when he was interviewing me for the job of VP of Engineering under him) was when he met me for lunch at Scott's Seafood.

Early on in the lunch interview he said "You've probably heard of me..." and talked a little about Tcl and his experience. Unfortunately, I had said "No" almost as soon as the first five words were out of his mouth.

So, then he was forced to tell me about Tcl (which I had never used) and went on to explain that Tcl was a really easy language for people to learn (which he illustrated with various interesting examples) and that it incorporated a complete regular expression engine from a lot of power was derived.

Right there, I blurted out "Don't you think those two things are contradictory? It can't be easy to learn and have regular expressions since regular expressions are one of the hardest things for a novice to pick up".

His eyes sort of bugged out of his head and he said, "Oh. Perhaps you are right. I hadn't thought of that".

Luckily for me it turned out that making John have a novel thought was the right way to impress him. Despite apparently having a big ego he turned out to be the best boss I ever had, I learned an enormous amount from him and later we co-founded Electric Cloud.

</comment><comment><USER3> I am a huge fan of Tcl. It's one of those languages that can be intimidating up front (when do I need $ and when not? etc) but it is in fact enormously simple once you get used to concepts like "everything is a command". There is no syntax. # (the comment character) is a command that ignores all its arguments. Tcl's event model makes many classes of applications (network servers, GUIs) much easier to write than in multi-threaded languages (tho' Tcl does do threads too if you need them).

The ability of Tcl to implement new control structures (e.g. Tcl doesn't have do...while but you can easily add it yourself) puts it up there with Lisp as a programmable programming language... I really don't understand why it isn't more popular with hackers. The tcl.tk Wiki has some "Lisplay" articles where people have experimented with Lisp-style coding in Tcl, it's surprisingly easy. And Tcl has the real-world libraries (e.g. GUI, Oracle access, etc) that working programmers need.

<comment><USER4> I don't think hackers hate Tcl because it's "intimidating". They hate it because it's verbose, slow, and lacking in abstraction power. (Last time I used it, associative arrays weren't first-class, i.e. you can't have a list of anonymous associative arrays; is that still the case?) Also, Tcl was originally aimed at the niche that Lua now occupies — lightweight embedded scripting language — but Tcl is 720k of code while Lua is 82k, and isn't verbose, slow, or lacking in power. Finally, the libraries available for Tcl, while they do cover some pretty important stuff, are a tiny fraction of what's available for C, C++, C#, Java, Perl, Python, or even Ruby.

The article says it's "more or less as fast as ... Ruby". Well, that's pretty slow!

The string-substitution execution model is easy to explain, and it's easy to do higher-order programming with, but it's very error-prone and very difficult to implement efficiently. If you use Tcl in a disciplined way, you won't have too much trouble with this, but it is not nearly the advantage that this article makes it out to be.

Tcl does have some nice advantages: it's optimized for use as a UI with an embedded DSL, not for use as a programming language, and its support for event-driven programming and securely running untrusted code are first-rate. Yosef K. (Yossi Kreinin) recently blogged about some of this.

Oh, and you say, "# is a command that ignores its arguments". You're wrong about that; try "# [set x 3]" or "# comments do not end at semicolons; puts hello" if you don't believe me.

<comment><AUTHOR> Well, Tcl is faster than Ruby and now we don't use the associative arrays we use the dict instead. What version of tcl have you used?

<comment><USER4> You seem to think that dicts aren't associative arrays.

I think the last version I did any significant amount of work on was Tcl 8.3. But I wasn't any kind of expert on it then.

It might be true that Tcl (8.6?) is faster than Ruby now, but the article that started this thread didn't dare to claim that, and these benchmarks of Tcl 8.5b3 don't support that claim:

[http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...](http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&lang2=yarv)

</comment></comment></comment></comment><comment><USER5> I used Tcl in the 1989-1993 timeframe as my default application configuration language. I stopped doing this when I realized the maintenance problems I was experiencing with my Tcl-based configurations were never going to go away.

Then for a while I used Apache httpd.conf style markup for configurations. That worked better but I missed being able to do the macro-style programming you can easily do in a dynamic language. I tried XML for a while until I realized that it wasn't much better and didn't make things easier.

Then I started doing more with Python and Ruby applications and found that in most cases I could easily just extend whatever configuration scheme the application used for my purposes.

These days I'm using Lua in everything I write that doesn't already use Python or Ruby for the same kind of things I would have used Tcl. Lua is efficient, easy to read by others and plays very nice with the surrounding environment.

So far Lua is working out pretty well but in fairness I spend a lot more time thinking about configuration issues up front than I did 20 years ago.

</comment><comment><USER6> Tcl is one of the things that got me curious about marketing. The implementation of the language is really nice in some ways (sure, it has its defects too, but so does everything else), so my conclusion was that the problem was elsewhere: marketing. It's hard to find such a cool project that has been marketed so poorly.

Some specific examples:

* Tcl, like Lisp, is flexible enough that it's possible to write an OO implementation in the language itself. That said, it's probably a good idea to call out to C to speed things up a bit. One of the problems that has dogged Tcl is that instead of having one standard OO implementation, it has had multiple, competing OO implementations, which are a splendid example of "the paradox of choice".

* Tk was _the_ cross platform toolkit for a long time. However, around the year 2000, instead of looking at things like Gtk and Qt and trying to improve, some of the head Tcl guys poo-pooed them and ignored them, with the result being that only now is Tk getting a nice looking look/feel update in the form of Tile. Even without Tile, there were some very simple tweaks that would have made Tk look nicer on Linux, that were ignored by the people at the top.

</comment><comment><USER7> This is out of date largely because recent improvements in Tcl have actually dealt with some of the limitations (apply and dict are the most significant for me, making Tk look more like the native widgets is another), more improvements are on the way in Tcl 8.6.

There are also some really useful things that do not get mentioned there (he says as much): sandboxed safe sub interpreters, easy deployment as a binary, two inline C extensions, etc.

<comment><AUTHOR> Yes It is out of date but I think the author did a great work explaining the language's features.

</comment></comment><comment><USER8> I have been able to do powerful things in TCL, and quickly. However, I believe it is one of the most difficult languages to debug, and its maintainability cost is _extremely_ high. You can't underestimate the risk that this is to a project.

Part of the problem is that the language doesn't defend well against bugs. Consider what happens if you pass your index and list arguments in the wrong order to "lindex"...it silently takes the index from your list, and then includes your intended index as part of the list! This is the kind of mistake that can silently appear to work, or fail in subtle ways, and it's not worth the debugging time in my opinion.

</comment><comment><USER9> It certainly looks cool. Another language in my "To play around with" list :D</comment>


Flippa hits new sales record: a million-dollar week - <AUTHOR> http://flippa.com/blog/news/flippa-new-sales-record/

<comment><USER2> \- average price of property was $2,675

\- 54% of listings sold in last 3 months

\- $40 million total sales

</comment><comment><USER3> I don't get it, all I see is a bunch of junk sites.</comment>


Ask HN: Do you want a service which will alert you about an airfare drop? - s-stude Hello HN!
This is a question mostly to travellers, but maybe everyone else will find it useful.
A part of our travel is a process of finding the lowest prices for tickets and the best connections. But sometimes the price itself is a good option to have a trip.
Do you think it will be useful to have a service, where you can enter your departure / destination city and subscribe to an airfare change?
Do you use any existing service? <comment><AUTHOR> There are 3rd-party sites that already do this, not to mention some or all of the travel sites.

</comment><comment><USER2> Kayak does this. I think most of the flight search flights offer it.</comment>


Ask HN: Amazon WorkMail as an alternative to Gmail? - <AUTHOR> I want to switch from Gmail and I'm considering the Amazon WorkMail. I know Proton and Fastmail exist but I'm curious if anyone has experience with WorkMail as a personal email?<p>https://aws.amazon.com/workmail/features/ <comment><USER2> I ended up moving to FastMail because workmail does not support catch-all addressing. It's just a hosted exchange server, so the UI is very similar to what you would get with Office365 or an outlook.com email address.

As with most paid email setups, WorkMail won't show you any ads or mine your correspondence for better ad targeting, so definitely a step up from Gmail. I recall you being able to choose the AWS region in which your WorkMail instance is deployed, whereas with FastMail your data falls under Australian jurisdiction.

<comment><USER3> As an aside, if you're a paying G-Suite user you don't get {mined for, bombarded with} ads either.

<comment><USER4> I've been considering switching to Protonmail since then my old emails would be encrypted.

A 10+ year old trove of emails is a target both for hackers and overzealous judges. (Stored Communications Act means they don't need a warrant for >6 month old emails)

[https://en.wikipedia.org/wiki/Stored_Communications_Act](https://en.wikipedia.org/wiki/Stored_Communications_Act)</comment></comment></comment>


Microsoft Accused of Hindering Firefox Browser - <AUTHOR> http://online.wsj.com/article_email/SB10001424052702304070304577394760696347108-lMyQjAxMTAyMDAwOTEwNDkyWj.html <comment><USER2> I really love my iPad, but I wish Apple would let Firefox into the garden. Apple is getting away with it because Safari is a webkit browser and is staying "on the edge", but there is no difference between what Microsoft is doing here and what Apple is doing.

For consumers, competition is very rarely a bad thing, and in this case, I can't imagine a case where it could be considered bad for users.

<comment><USER3> >there is no difference between what Microsoft is doing here and what Apple is doing.

There is a difference and the difference is that Windows RT will allow Firefox and Chrome and other browsers to run in Metro mode, just not in the desktop.

Edit: I was wrong.

<comment><USER4> However, the restrictions on the sandbox for Metro style apps mean that alternate browsers would either have to be skins around the IE engine, or be very slow (because it's not possible to run dynamically compiled aka JITted code). That is why there is a special exemption for "Metro style enabled desktop browsers" (which appear to the user as Metro style apps but have all the capabilities of desktop apps) on Windows 8 (x86), which is what Metro style Firefox will use.

<comment><USER3> Interesting, I stand corrected in that case. I assumed that the x86 Metro app would work on the ARM version as well.

</comment></comment></comment></comment><comment><USER5> This is probably going to become a major point of contention. There is a demonstrable security benefit to restricting applications to a subset of available APIs and vetting or at least signing all applications that are installed. The iOS platform is very secure because of this. Android also does well by gating its app store. But if you restrict apps in this way, you are setting up an environment where it is easy for a first party to control a de- facto monopoly.

Openness is great for competition and innovation, but it has inherent security problems. There will always be a tension here.

<comment><USER6> That's an interesting way of framing it. I generally come down on the side of openness, but it makes me wonder if something like a "right to be available absent proof of maliciousness" (with part of the hurdle being that a developer would have to demand their right to be included in some non-trivial way) would be a useful compromise.

</comment></comment><comment><USER7> Given that Microsoft has already moved to ban Linux from ARM devices at the UEFI level, it seems like they believe strongly that ARM is going to be an important battleground for them:

[http://www.bit-tech.net/news/bits/2012/01/16/microsoft- block...](http://www.bit-tech.net/news/bits/2012/01/16/microsoft-blocks-linux- arm-hardware/1)

[edit - changed "BIOS" to "UEFI"]

<comment><USER3> >Given that Microsoft has already moved to ban Linux from ARM devices at the UEFI level..

Uhh, Microsoft cannot and hasn't done anything like that.

They can't stop Android tablets from shipping can they?

They're more likely going to subsidize Windows RT tablets by charging a smaller license fee, and trying to compensate that with the money from Windows App Store/Bing/Music etc.which they lose if users are allowed to change the OS.

That's like saying Microsoft banned all other consoles, just because they have a locked bootloader on the XBox.

<comment><USER6> Microsoft is at the very least trying to ban dual-booting of Windows RT tablets. To me, that is very significant.

Also, Microsoft certainly can provide OEMs financial incentives for not making Android tablets. As you note, they're already talking about subsidizing Windows RT devices (one of the justifications for blocking dual-booting) and Microsoft has done worse before...

<comment><USER3> I do not know why there is this expectation that if something runs Windows it should be able to run other OSes. First of all this is not Windows, and none of the millions of Windows programs will run on it. Why should Microsoft be denied the freedom to do the same things that Apple is succeeding very well with(and supposedly killing MS in the post-PC world, if you see posts on here) ?

<comment><USER6> Some of us think that Apple shouldn't be permitted to do some of those things either (e.g. banning side-loading and locked bootloaders).

</comment></comment></comment></comment></comment><comment><USER6> I wonder if Microsoft would have let Firefox onto Windows-on-ARM devices if they'd decided to take Bing's money instead of Google's. I could see them doing that, but I could also see their desire to emulate Apple trump their desire to work more closely with a new partner.

<comment><USER3> How is allowing Firefox in Metro mode on Windows RT tablet "emulating Apple" ?

Edit: I was wrong.

<comment><USER6> You can't write Firefox in Metro mode. The only way you're getting Firefox with a Metro interface on the desktop is the special "browser mode" that had to be invented. That "browser mode" isn't available on Windows RT (and shouldn't be the way to solve this problem anyway because it is a terrible hack).

<comment><USER4> Any ideas for a better solution to the problem? (not snarking, genuinely curious to hear your thoughts)

<comment><USER6> Have user-grantable permissions for escaping from the Metro sandbox? (JIT permission being the most obvious, of course) That might devolve into a "de- facto" desktop permission at the start, but if they were clear that the permission model was in flux I could see incrementally turning it into something reasonable. And saying "your app might/will break in the future" is much nicer than saying "people can't get your app at all".

<comment><USER3> History has shown that it never works and the users can be coerced to do anything to make their app work and are incapable of deciding what's malware and what's not.Case in point, declaring app access permissions in Android. Most software seems to have no trouble with user adoptions while requesting every permission available like making phone calls.

>but if they were clear that the permission model was in flux I could see incrementally turning it into something reasonable. And saying "your app might/will break in the future" is much nicer than saying "people can't get your app at all".

The problem is that with the first breaking change, users will be annoyed and MS will regardless take the blame for it.

Also the iPad has proven to be a roaring success with the very same restrictions.

<comment><USER6> I'd say plenty of permissions systems have been a success, including the app permissions system in Android. Does it have tons of rough spots and issues? Absolutely. Handling permissions is a hard problem no one has cracked. But Android's system has also unequivocally has provided a net positive value to users and the platform.

First, there's the baseline transparency. Android hasn't had Path-style surprises because things like whether or not an app is accessing the address book or your location are out in the open.

Second, the permissions system (including negative reviews driven by it) encourages app developers to not just request permissions, but explain why they are needed. Not everyone does that, but plenty of the apps I've used do. Among other things, I can wish that were more integrated and consistent (e.g. a mandatory text string provided along with the request to shift the default), but, even today, this valuable information ends up in the app description where everyone can see it.

Third, there's all sorts of potential for tools you can build on top. It's easy to answer questions like: "Which apps access my location and can send SMSes?" There have also been attempts to revoke permissions that users didn't want to give. This doesn't always work well because apps usually don't gracefully handle not getting an expected permission, but most of the technical infrastructure is there, so it is a logical future step. And so on.

I'm not saying a permissions system will be wonderful out-of-the-box, but it is a good foundation on which you can make things better in the future, rather than settling for a false choice today.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> But a Metro version of Firefox is being worked on[1]: in light of that, how does the removal of desktop style apps impact Mozilla? It does not appear to.

[1]: <https://wiki.mozilla.org/Windows8>

<comment><USER6> Did you read the "Open issues/risks" section? That makes it clear that any Metro for Firefox on Windows 8 depends on special accommodations from Microsoft that (so far as we know) won't be available on ARM.

<comment><USER8> I did, but none of that is mentioned in either the original Mozilla blog post or this article. We have no reason to believe that disabling desktop mode precludes an application acting as a Gecko rendering bridge for a Metro UI. They seem completely unrelated: in fact, the only way they could be is if one expects a Desktop Firefox to run in the background and serve pages to Metro. That's not listed in their design plans and, furthermore, is not how IE works on the same platform.

I will admit to not having read the Application development guidelines for Windows RT. It could potentially be a sandbox violation, depending on the aforementioned guidelines - however, that's a completely different issue, and it's not "Microsoft locking Mozilla out of the market by removing desktop mode."

<comment><USER6> As someone else notes, Firefox needs to break out of Metro to JIT JavaScript, at the very least. For third parties, there's nothing other than Metro on ARM, so how would that be possible (absent special accommodation from Microsoft)?

</comment></comment></comment></comment><comment><USER4> This is a surprisingly well-written and accurate article.

</comment><comment><USER9> How is this remotely related to antitrust(any more than the iPad i.e) ?

Desktop Windows gains it's monopoly leverage from running Win 32 apps and people are forced to run it for compatibility. None of those programs will ever run on Windows RT. Windows RT is basiscally starting from zero, just like the iPad did.

Just because it has Windows in it's name does not mean it's subject to antitrust. What next? Insinuating that Windows Phone should be subject to anti-trust restrictions that the iPhone or Android is not?

<comment><USER6> Um, there's going to be Office for Windows RT. That's certainly leveraging one of Microsoft's monopolies.

<comment><USER9> That seems to be quite a stretch.

MS is rumored to be working on Office for the iPad. If that's true then will it get them off the hook?

<comment><USER6> Offering Office on other platforms doesn't mean they're not leveraging it. After all, which platform is it going to work _best_ on?

<comment><USER10> This is ridiculous. Of course I hope it is going to work best on the MS Tablet. Why not? It'd be a fail if it wouldn't work best on their own OS. There is nothing whatsoever wrong with that, in fact, it is called decent engineering. And if e.g. Apple does not want to provide the same access to iOS as MS has to Windows, it will not work as slick.

Also, I heared Apple is leveraging Safari on iOS, where is the law?

<comment><USER6> The difference between Office and Safari is Microsoft has a monopoly with Office and Apple doesn't with Safari.</comment></comment></comment></comment></comment></comment>


Ask HN: Should I try Lead Generation? - <AUTHOR>

Hey HN, I'm posting this under a fake name because I'm kind of embarrassed to be asking this.
Today learned about "leadgen" sites where you basically put up a form, get customer information, and then sell it to someone who needs that customer. Apparently its a huge business (for which there was even a conference in Vegas recently).
By day, I work doing datamining / machine learning with Hadoop. I'm comfortable with doing A/B testing in Rails, and I'm competent in photoshop. Surely I could compete on a technical level, but is this even worth spending time on?
I realize the market for the "big 4" (mortgages, loan modification, automotive, online schools) is very saturated. That said, I think there may be a lot of opportunities in the local space for smaller categories: handymen, personal trainers, wedding photography, (maybe cosmetic surgery?) etc.
Let me give you an example: The other day our phone rang and it was a man in his thirties who was short on work. He asked my wife if we had any handyman work we needed done. My wife said that we didn't and he continued by suggesting a list of work he could do (plumbing, painting, yard work, etc.) We politely refused because we don't need anything done, but I felt bad for the guy.
He seems like an ideal candidate for selling a home improvement lead. I can only imagine that in this economy there are many more individuals and companies like him.
I don't want to get rich, I just want to make a couple hundred thousand to pay off my mortgage.
So HN: what are your thoughts? Is this a sleazy, saturated market for which I will be selling my soul in exchange for pittance? Or is it a viable side business for making a little cash? Any legal issues or pitfalls you want to warn me about? <comment><USER2> From an ethical perspective, I think it just depends on how you will use the leads. If you make sure you're giving the leads to a scrupulous company who will offer the customer a valuable service that (s)he was looking for, then I don't see any ethical problem there.

From a business perspective, I think you'd need to figure out who would buy the leads after you've generated them. Perhaps you should start by coming up with a niche with a dearth of lead generators, find a company targeting that niche, and ask them if they would be interested in buying leads. By ensuring there is "customer" for your leads you can save yourself wasted time. Customer development (a la Steve Blank) for lead generation, so to speak ;)</comment>


Ajax URLs and breaking the back button - <AUTHOR>

What's up with named-anchor URLs breaking the back button?
I was reading a different thread (http://news.ycombinator.com/item?id=2161405), and when I followed it, I was taken through a series of redirects: https://github.com/documentcloud/backbone/issues#issue/201 -> https://github.com/documentcloud/backbone/issues/201/find -> https://github.com/documentcloud/backbone/issues/issue/201
The redirect form the URL with the named anchor redirects to the find URL via JavaScript's window.location property, and the find URL redirects to the final URL via a HTTP Location header.
When I reach the final page and click my back button, I'm taken to the named-anchor URL, which initiates the series of redirects, taking me back to the final page.
I know the named-anchor URLs are used so that Ajax interactions are reflected in the address bar, but it's annoying when they break expected behavior when used to link directly to a page. (In fairness, this doesn't appear to be a problem in Chrome; I'm using FF)
Twitter's also been bad about this recently. (Their URLs look like they're tailored for Google, to me: http://code.google.com/web/ajaxcrawling)
Companies should make sure their code doesn't end up trapping users in a redirect loop.
In GitHub's case, I believe using location.replace instead of window.location for the first redirect would solve the problem, although I'm not sure because I haven't tried it.
Is it possible to have these types of redirects without breaking the back button? If so, why are large sites making this mistake? <comment><USER2> yes, its possible. there are lots of sites that do make use of it well/correctly.

the reason why its difficult is because it turns the app into a ajax state machine. navigation is much more programmatic, which makes the possibility of something screwing up much higher. especially in a larger, more complex system.

<comment><USER3> Not if you use HTML5's new state management. But I thought GitHub did. I've never had problems with AJAX history navigation but I know that Firefox users complain about it all the time due to how WebKit handles javascript instant redirectts.

<comment><USER2> its relatively new. not all sites that do this are going to have made that jump. github might. other sites that have problems definitely don't.

its also still totally possible to screw up html5's state management.

</comment></comment></comment><comment><USER4> I think it's a different issue, but Google Analytics is terrible about breaking the back button. It drives me crazy every day.</comment>


Cookies Lack Integrity: Real-World Implications - <AUTHOR> https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng <comment><USER2> VU#804060 is talking about "cookie forcing". This is not a new discovery. Here's Chris Evans (not the actor) talking about it in 2008: [http://scarybeastsecurity.blogspot.com/2008/11/cookie- forcin...](http://scarybeastsecurity.blogspot.com/2008/11/cookie-forcing.html)

The best solution is to preload HSTS on a domain and include all subdomains, and we've been saying that for years. That prevents any HTTP connections, although it's obviously not an easy solution in many cases.

The USENIX paper does suggest some unilateral changes to cookie semantics to address this issue, but any such changes have eye-watering compatibility concerns and could only be deployed after a lot of testing.

<comment><USER3> _" The best solution is to preload HSTS on a domain and include all subdomains"_

That's the great thing about HTTPS/SSL security. Every attack, every vulnerability, every problem with performance is met with "just make sure your server enables XYZ and blah blah blah is updated and make sure the clients are only connecting from chrome while standing on one leg and singing the national anthem while looking at a picture of the Pope. So yeah, it's actually really secure.

When are we going to accept that it's a fool's errand. SSL is a hopeless case and design something better for today's world?

<comment> grey-area We'd all love to see the plan.

<comment><USER3> Here's one: [http://cr.yp.to/tcpip/minimalt-20130522.pdf](http://cr.yp.to/tcpip/minimalt-20130522.pdf)

<comment> grey-area Thanks.

</comment></comment></comment></comment></comment><comment><USER4> "man in the middle can do nasty thing, here is a castle of vulnerabilities we built on top of already having pwnd the communication channel"

related [http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...](http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx) "It rather involved being on the other side of this airtight hatchway"

<comment><USER5> I can't for the life of me find it, but there was a paper a few years ago about evading App Store policies by purposely introducing vulnerabilities in your app. The idea being that e.g. you have a buffer overflow and the app makes a specific network request that exploits it, resulting in code execution free from Apple's policies. So that ONT post is a bit short-sighted in thinking bugs that don't result in privilege escalation aren't "security holes."

<comment><USER6> Coincidentially I heard about this at a recent talk - is it this:

[http://www.imore.com/jekyll-apps-how-they-attack-ios- securit...](http://www.imore.com/jekyll-apps-how-they-attack-ios-security-and- what-you-need-know-about-them)

Jekyll apps in App store

<comment><USER5> That's it, thanks!

For anyone wanting to read the paper itself, the link the imore.com article is broken. Use this one instead: [http://www.usenix.org/system/files/conference/usenixsecurity...](http://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_wang- updated-8-23-13.pdf)

</comment></comment></comment></comment><comment><USER7> I am more afraid of the man at the browser and the man in the browser rather than middleman attacks.

For instance a user might be trying to use your paid service for free or otherwise get information they are not supposed to and if you are using cookies for authentication, authorization or application state, the user could modify the cookie and break your system. Not to mention the cookie is a vector for XSS, buffer overflows, and other troubles.

So if you are sending anything in a cookie that you don't want people to tamper with you should cryptographically sign it, or alternatively, send them a single opaque random identifier that points to a session or request record inside the server. There are way too many cookies on web requests now, and just from the viewpoint of speed, the opaque reference is a performance win in the age of Hazelcast.

Replay attacks can be made but there are many countermeasures, such as adding a timestamp and a nonce.

This defends against the major threat (the would-be user who wants to abuse your web site) vs a more hypothetical case (sophisticated outsider wants something.)

<comment><USER8> What you're talking about is defending the site. That's great and of course you should do that. What the paper talks about is defending the user. The example they give is being able to inject cookies then override the GMail chat widget with the attacker's account.

Such an attack doesn't put the site at risk - Google is fine. But it puts Google's users at risk, as they are signed in, yet chatting on another account.

<comment><USER9> The point the GP was trying to make, I think, is that if the site's operator has cared enough about _their own_ security to cryptographically sign their cookies, then this provides security to the users as a free benefit, because a MITM wanting to attack _the user_ doesn't have the site's signing key either.

<comment><USER8> Cookie signing doesn't fix this. Attacker will just login, take his own signed, valid, session cookies, shove them into Victim. Now Victim uses whatever.com and Attacker can see.

The example they gave was being able to do this to Gmail. Victim is logged into Gmail, but the Gmail Chat widget is logged in as Attacker.

</comment></comment></comment></comment><comment><USER10> I haven't dug around my browser config or the Extensions store in awhile. Does anyone happen to know if IE/Chrome/Firefox can be configured to not accept cookies from non-HTTPS sites?

<comment><USER11> Chrome plug-ins have a lot of control over network requests through the webRequest API[1]. They're easy to write - email me if you have questions.

[1] [https://developer.chrome.com/extensions/webRequest](https://developer.chrome.com/extensions/webRequest)

"Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight"

</comment></comment><comment><USER12> Browsers should consider not showing a green lock unless a site uses HSTS.

<comment><USER8> But even with HSTS, if it wasn't preloaded, an attacker could inject cookies on the first visit (then take user to real HTTPS site). Or, if the domain doesn't have full HSTS for all subdomains, there's still a potential vuln as you can inject from non-HSTS subdomains. The paper notes that Google and some other big properties have technical issues in deploying global HSTS.

</comment></comment><comment><USER13> This exposes a weakness in the "double-submit cookie" CSRF defense technique.

[https://www.owasp.org/index.php/Cross- Site_Request_Forgery_(...](https://www.owasp.org/index.php/Cross- Site_Request_Forgery_\(CSRF\)_Prevention_Cheat_Sheet#Double_Submit_Cookies)

</comment><comment><AUTHOR> Here's the research paper presented at USENIX [https://www.usenix.org/system/files/conference/usenixsecurit...](https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper- zheng.pdf)

</comment><comment><USER14> Another great argument for using signed cookies.

<comment><USER15> Exactly. A better, or at least more general, mitigation than enabling HSTS (though that's a good idea anyway), is to not design your web application in such a way that a modified cookie in the client creates a vulnerability. Since cookies are stored in the client, they are always going to be susceptible to malware on the user's machine. So, trusting that the contents of a cookie were authored by the service receiving them is a bad idea in general. Cookies should be stored along with some additional information that verifies their authorship.

A relatively simple way to accomplish this is to have your application include an HMAC in the cookie contents, and verify it whenever the cookie is received. e.g, if you are storing $session_id in a cookie, change your cookie contents to be "$session_id:$hmac_of_session_id", and verify the HMAC every time a cookie is presented.

Now a user, or malware, or a MITM, is not in the position to take over or modify a different user's session simply by altering the cookie, since they will not be able to produce a valid HMAC (the key is never shared with the user).

If even storing the key in your web frontends is too risky, you could use RSA or DSA signatures, only store the public key in the web frontend that verifies cookies, and store the private key in a more hardened cookie-signing service that isn't directly exposed to external networks. This service can be invoked when new sessions are created or upon user login, if applicable.

On top of this, if the client supports ChannelID, you should include the ChannelID in the message that is HMAC'd, so that stolen cookies cannot be reused on other machines.

<comment><USER16> > Now a user, or malware, or a MITM, is not in the position to take over

I fail to see how this fixes this issue. I can just set my cookie to $their_session_id:$hmac_of_their_session_id, or I can set their cookie to $my_session_id:$hmac_of_my_session_id

Sure, I can't modify signed cookies. But I'm still in a position to take over their session.

<comment><USER15> > I can just set my cookie to $their_session_id:$hmac_of_their_session_id

If you can steal somebody else's cookies (which are not Channel-bound) then that's true. If you can only steal or predict somebody else's session ID's, the HMAC provides protection.

It's not atypical for session IDs to be simple counters that get incremented for each new session. If your session ID is 100042, it's a pretty good bet that 100041 and 100043 are valid session IDs as well, and without HMAC, a user could take over these sessions trivially.

The even better mitigation to cookie theft, which I also mention, is TLS ChannelID. ChannelID creates a unique private/public keypair for each new TLS connection, and sends the public part along in the TLS handshake. Then, when you resume sessions from the same machine, you can prove that you have the private part and the server can accept your existing cookies. With this approach, cookies are no longer bearer tokens and stealing cookies becomes worthless.

This can be hardened even against local malware running as the same principal as the user doing the browsing if the browser's ChannelID implementation generates and stores the private key inside a TPM or HSM.

<comment><USER13> > _If you can steal somebody else 's cookies (which are not Channel-bound) > then that's true. If you can only steal or predict somebody else's session > ID's, the HMAC provides protection._

Session fixation. You don't need to steal any cookies. The attacker can plant his own session ID cookie in the victim's browser using the OP exploit. Using signed cookies doesn't change this attack at all.

</comment></comment></comment></comment></comment><comment><USER17> I think of the following:

\- store only session ID in cookie

\- regenerate session ID upon privilege escalation (login, what else?)

\- destroy session upon logout

That being the case, is this really capable of doing much damage? Especially once you enable HSTS.

<comment><USER18> This is still vulnerable to the same kinds of attacks you can do with login CSRF: [http://seclab.stanford.edu/websec/csrf/csrf.pdf](http://seclab.stanford.edu/websec/csrf/csrf.pdf)

Though the attack scenarios for that are always very tenuous.

</comment></comment><comment><USER19> _solution: Deploy HSTS on top-level domain_

yeah easy for you to say

<comment><USER20> Why? What's hard about HSTS? Although they don't include subdomains.

<comment><USER21> There is still the issue of trust on first use. Unless the domain is preloaded in the browser as HSTS there is no assurance that there won't be at least one HTTP request.

<comment><USER22> DNSSEC, TLS DANE is the proper solution for this.

<comment><USER8> DNSSEC means creating irrevocable CAs that'd be under essentially-direct control of major governments. No thanks. At least with the current system, if a CA fails to act proper, they can get smacked back. With DNSSEC, if .com starts issuing *.com certs, there's no recourse.

<comment><USER22> Huh? Your site can be already completely hijacked by the same actors. Your browser trusts a lot of CAs so VeriSign (or whoever operates the .com zone) can already issue .com certs. And your only hope is to preload your cert (which is a Chrome only thing, and pretty inefficient and inflexible).

The Convergence Project with notaries is an even better solution.

But using the DNS as the authoritative source of data and using external parties to keep an eye on that would both lead to efficiency (performance, flexibility) and security (as in from the State).

</comment></comment></comment></comment></comment></comment><comment><USER23> So is this a real issue or a theoretical one? Are people actively using this to do harm or is something someone could do?

</comment><comment><USER24> Why isn't cert.org using HTTPS by default?</comment>


PoC Attack Escalates MikroTik Router Bug to 'As Bad as It Gets' - <AUTHOR> https://threatpost.com/poc-attack-escalates-mikrotik-router-bug-to-as-bad-as-it-gets/138076/ <comment><USER2> > The licupgr binary has an sprintf that an authenticated user can use to > trigger a stack buffer overflow.

The printf family is responsible for so many problems. Few people seem to know how to use it safely, or when to use something else.

> only approximately 30 percent of vulnerable modems have been patched, which > leaves approximately 200,000 routers...

Welcome to the botnet. Combining the two bugs gives root, and that's a large enough collection of devices to target.

<comment><USER3> >Few people seem to know how to use it safely, or when to use something else.

I was taught printf should only be used for quick n dirty debugging.

<comment><USER4> Please just use a decent logging library and debugger... it will up you productivity, you will learn important skills and you will write cleaner code and you will prevent issues like this one.

</comment></comment></comment><comment><USER5> This isn't as bad as it sounds - it only works if the attacker has access to the management interface. If you're exposing that unfettered to the web at large, imo you deserve what you get.

<comment><USER6> Domain Reflection is a thing, load a webpage on domain www.example.bad with low DNS TTL, then repoint it to common IPs for management interfaces, make AJAX call. Of course a lot of routers try to filter it but it works in a surprising amount of installs to this day.

Another entry point could be other devices in your network that have been taken over to some extend (or maybe even an app on your phone).

</comment></comment><comment><USER7> I used Microtik routers for a few years, I felt nerdy and in control and all that. Until one day one of them bricked itself completely while updating itself. I replaced it with a off-the-shelf consumer one and realised immediately that it was a LOT faster than the fancy Microtik. Experience of One of course, but well, I never bought another.

<comment><USER8> I have no experience with Microtik, but you dont seem to be comparing like generations. A newer router will beat an older one just due to the march of technology.

<comment><USER9> I had the same experience with Mikrotik routers. Same generation devices. Also suffered from random drops of the network. Very good transmission distance when it worked.

</comment></comment></comment><comment><USER10> tl;dr this is the "proof of concept":

GET /ssl_conn.php?usrname=%s&passwd=%s&softid=%s&level=%d&pay_typ'e=%d&board=%d HTTP/1.0

Attackers will not be able to use that, nor will they care. There are already plenty of routers vulnerable to RCE on the Internet.</comment>