Wolff PHP SQL Injection Framework - chupa-chups https://github.com/Usbac/wolff-framework/blob/master/system/core/DB.php <comment> chupa-chups I really don't want to shame people, but since this "framework" does everything wrong one can think of in the simplest case of security, I have to warn others :-(

If the author is very young I hope he learns from this.

[https://stackoverflow.com/questions/60174/how-can-i- pr](https://stackoverflow.com/questions/60174/how-can-i-pr) event-sql- injection-in-php</comment>


Show HN: Pyctuator – Monitor Python Web Apps Using Spring Boot Admin - <AUTHOR> https://github.com/SolarEdgeTech/pyctuator <comment><AUTHOR> Hey HN, Wanted to share with you our first Open Source project here in SolarEdge.

Pyctuator is a Python implementation of the Spring Actuator API, with one-line integrations for Flask and FastAPI applications. Once integrated, you can easily leverage existing Spring Boot Admin instances to monitor your Python app.

This is useful if you're a Java shop that needs to quickly spin up a Python microservice (e.g. for Machine Learning). Until you set up a proper monitoring solution for your new Python microservice, you can integrate Pyctuator and use your existing monitoring infrastructure.

We acknowledge this might be a niche use-case, but it has been tremendously helpful for us as a Java shop to be able to quickly spin up some Python microservices when we needed some of Python's power in the ML world.

On a personal note, this release is very exciting for me. I've been leading the Open Source initiative in SolarEdge for the past few months, with the goal of contributing back to the community which is so valuable to us and the rest of the industry.

This is just our first project, with more projects coming soon. Hopefully this initiative would grow to a substantial contribution to the Open Source world.

Would be happy to answer questions and get some feedback!</comment>


Tutorial: HTTP Client in C with libdill - <AUTHOR> http://libdill.org/tutorial-sockets.html <comment><USER2> Those titles suck. Next week I post my 'Wget in 2 lines of Bash code':

      #!/usr/bin/env bash
      curl "${@:2}"

I mean, if you use a lib it is no wonder you have a low line count and the result is in fact as much Wget as curl is wget (probably even less).

How about 'Tutorial: HTTP Client in C with libdill'?

<comment><USER3> OK, changed. Thanks!

</comment></comment><comment><USER4> If this is wget, my bicycle is a car.

This isn't "Wget in 50 lines of C code", just `wget --help` page is 192 lines.

<comment><USER5> It's just the title that's a bit simplified. First paragraph already says:

"This tutorial is meant as an introduction to libdill socket library. We are going to develop a simple version of wget utility, that can be used to download webpages from the net."

<comment><USER6> a bit simplified? title would be considered clickbait if it were a webpage.

<comment><USER7> Editorialized clickbait from the HN user, that is. The original is just fine.

<comment><USER8> Apparently the author and HN user are the same person.

<comment><USER7> Oh, wow! Indeed. That's disappointing.

</comment></comment></comment></comment></comment></comment><comment><USER9> libdill looks interesting, but I'm a bit surprised by the lack of prefix in the functions, types, etc. C does not have namespaces, but open source libraries usually use short prefixes for readability. What do you think ?

</comment><comment><USER10> It is disingenuous to plug your own library with a click bait title and no indication that you are the author.

</comment><comment><USER11> Port to Golang using stdlib:

[https://play.golang.org/p/vXTpR9IjBxV](https://play.golang.org/p/vXTpR9IjBxV)

<comment><USER12> wget has a default read timeout of 900s, yours has no timeout.

</comment></comment><comment><USER13> +k lines of libdill.c

<comment><USER14> … and don't forget libc!

<comment><USER15> ... and don't forget the OS. It's a deep rabbit hole.

<comment><USER16> It's all abstractions and sometimes concretions. Then there's leaky abstractions where you need to know details of the implementation in order to use it.

</comment></comment></comment></comment><comment><USER17> libdill is about concurrency made easy (according to the home page). But this tutorial has no concurrency as far as I can see after a quick read. That's a bit weird way introducing a library.

</comment><comment><USER18> It would be interesting to see a performance comparison between libdill and goroutine for concurrent network requests.

</comment><comment><USER19> What is the difference with libcurl ?</comment>


How to mod a Porsche 911 to run Doom [video] - <AUTHOR> https://www.youtube.com/watch?v=NRMpNA86e8Q <comment><USER2> I tried that, and kept crashing. Someone told me I should update the driver.

<comment><USER3> Plagiarizing a 2 month old Youtube comment, really?

<comment><USER2> Not sure what comment you're referring to?

<comment><USER3> The one with the second highest thumbs up: [http://imgur.com/4HkZ0Wx](http://imgur.com/4HkZ0Wx)

<comment><USER2> Ok, I didn't know. The joke really isn't that creative, so not surprised someone else also thought of it. I think you should maybe keep that in mind next time you accuse someone of plagiarism.

<comment><USER3> I thought it was unique enough for it to be unlikely a coincidence, but if I was wrong I sincerely apologize for the accusation.

</comment></comment></comment></comment></comment></comment><comment><USER4> If anyone's wondering why the toaster is there: [https://www.youtube.com/watch?v=vI7tWd7B3iI](https://www.youtube.com/watch?v=vI7tWd7B3iI)

<comment><USER5> Edit: I was actually being serious. I guess I'm more gullible today than usual. Now that I re-watch it and read the comments it is very clearly a joke.

<comment><USER6> It's fake too. The cmd party makes it pretty obvious.

<comment><USER5> It wasn't obvious to me. I was skimming and assumed I missed the part where he installed or compiled a program to flash the chip.

After re-watching it, it is more obvious.

</comment></comment></comment></comment><comment><USER7> Looks fake to me. This part: [https://youtu.be/NRMpNA86e8Q?t=169](https://youtu.be/NRMpNA86e8Q?t=169)

<comment><USER5> I feel like Occam's razor applies here in a non-intuitive way.

Either he:

1\. Recorded a video of him driving a car and frantically pressing the horn

2\. Made a screen capture of Doom that matches the gun fire, turns, and weapon changes perfectly to his car video

3\. Did some video editing to superimpose the video including several cases where his thumb goes over the screen while shifting

Or....

1\. He put software on the car console (which is pretty much a full computer)

2\. He actually mapped the controls to data being read from the onboard computer

I mean, I couldn't do this... one I don't know how to write software for a Porsche console and two I can't afford a Porsche :-P but faking it seems like way more work and worse ROI than actually doing it.

Edit: alternatively in some cars the console actually takes RGB or HDMI input and you don't even need to run directly on the console assuming ODB-II has enough info to read the input signals. I can totally see myself doing this if I had the time. Seems fun (albeit a bit dangerous for my taste)

Edit 2: It could still be a fake but it's not unreasonable to think it isn't.

<comment><USER8> Honestly, if you've watched people who are actually good with After Effects, this isn't really all that much work. And see, look how clever After Effects is: [https://helpx.adobe.com/uk/after-effects/how-to/rigid- mask-t...](https://helpx.adobe.com/uk/after-effects/how-to/rigid-mask-tracker- aftereffects-cc.html)

<comment><USER5> It might very well be my experience bias. As someone who is good at software engineering and bad at video editing, to me actually making it work seems more interesting and doable.

</comment></comment></comment></comment><comment><USER9>
        This is how it ends;
        not with a whisper
        but with a geek running Doom on a Doomsday machine.

<comment><USER10>
      Somebody had to, no one would
      I tried to do the best I could
      And now it's done, and now they can't ignore us...

<comment><USER11> You could likely run Doom on a sniper scope. [https://arstechnica.com/gadgets/2013/03/bullseye- from-1000-y...](https://arstechnica.com/gadgets/2013/03/bullseye- from-1000-yards-shooting-the-17000-linux-powered-rifle/)

</comment></comment></comment><comment><USER12> Reminds me of this thing that was released/first shown at the "Revision" demoparty two weeks ago. [https://www.youtube.com/watch?v=FJ6LvHBWGio](https://www.youtube.com/watch?v=FJ6LvHBWGio)

</comment><comment><USER13> This sits right at the intersection of insane and awesome.

Note the WASD controls are replaced by the throttle, brakes and steering wheel. The horn is for shooting the gun, and the gearbox controls the currently selected gun.

</comment><comment><USER14> VROOM II

<comment><USER15> Vroom is in fact a 1991 game on the Atari ST: [https://www.youtube.com/watch?v=hxA8yEBfODg](https://www.youtube.com/watch?v=hxA8yEBfODg)

</comment></comment><comment><USER16> Seems great, but has anyone tried to run Doom on a Tesla yet ?

</comment><comment> rodrigo-mx It becomes so real that you can die in real life too

</comment><comment><USER17> at the risk of embarrassment, what is the amazing music riff at the end? no I'm not kidding, those are amazing tunes.

<comment><USER18> No need to be embarassed, Doom had great music by Bobby Prince.

Enjoy: [https://www.youtube.com/watch?v=cixW6rogZ48&feature=youtu.be...](https://www.youtube.com/watch?v=cixW6rogZ48&feature=youtu.be&t=6s)

If you like that, then you might like Quake's soundtrack by Trent Reznor of NIN. [https://www.youtube.com/watch?v=qVOHTGYoM6E](https://www.youtube.com/watch?v=qVOHTGYoM6E) Quake's is less chiptune and more real.

</comment></comment><comment><USER19> What os?</comment>


Natural selection has trouble explaining this bugs horns - <AUTHOR> https://www.popsci.com/natural-selection-doesnt-tell-whole-story/ <comment><USER2> Maybe it has altogether some ither function</comment>


"How hard can it be to implement?" - <AUTHOR> http://answers.37signals.com/basecamp/52-how-can-i-move-or-copy-to-do-lists-between-projects#reply_6986

<comment><USER2> Is there really no simpler way to solve this problem?

"Moving a message needs to move all of the message's comments, and all of the comments' files, and all of the comments' files' versions."

Why can't you just change some top level reference in the database? I'm imagining a Projects table and a TodoLists table. Each TodoList has something like a projectID foreign key right? Why can't you just change that and automatically have all of the messages, etc, come along with the TodoList?

"But I hope you will see that sometimes even the simplest feature can be much more complicated than it looks from the outside."

I agree there, just wondering why the simple solution doesn't work in this case.

<comment><USER3> You're falling into the same trap all programmers do when they perpetually underestimate the time to accomplish any task. The main difficulty in estimating time is that you don't know what you don't know, so you have to actually get into the nitty gritty of implementing it, and if you're smart enough you'll hopefully catch all the requirements before you actually launch it.

I'm going to take Sam's word on this that there is _not_ a simpler way, because he's the one working on it, and I trust the competence of the 37s dev team. That's not to say that some armchair analysis here on HN might not have valuable insight, but without actually seeing the code, and in light of the full list of points Sam mentioned, I doubt very much that there is a much simpler solution of any form.

<comment><USER4> _> The main difficulty in estimating time is that you don't know what you don't know, so you have to actually get into the nitty gritty of implementing it, and if you're smart enough you'll hopefully catch all the requirements before you actually launch it._

That's certainly true for a low-level, high-precision estimate, which you can only make when you've got detailed requirements. Prior to that you still need to be able to deliver an estimate, and the best approach to take is to provide an estimate with Quantified Uncertainty. The phrase is important, because the estimate is for managers and managers are all about quantifying risks, and uncertainty in a development estimate is definitely a risk.

When you say "I don't know how long this will take, because I don't know how much I don't know about the solution" you're giving an estimate with uncertainty, but you're not quantifying the uncertainty. It's got no bounds, it's limitless. Managers can't make any decisions with that, so it's useless information. But if you say "This will take 4 to 8 effort weeks, and I'll be able to give a more precise estimate after 2 effort weeks of investigation" that gives your manager something to work with. You're still uncertain, but you've quantified the bounds on the uncertainty, and decisions can be made. For example, solving the problem might not be worthwhile unless it happens within the next two weeks (eg: to meet a release deadline) so the manager can just delay the work until later.

The trick with this approach is setting the bounds. The man who taught me this style of estimating called it a Surprise Range. The lower bound should be an estimate such that you'd be surprised if it took less effort than that, and the upper bound should be an estimate such that you'd be surprised if it took more effort than that. Given whatever information you have about the requirements, you just keep pushing your bounds until you can honestly say "I really don't think it would take less/more effort than that."

As you get more experienced, you'll naturally start accounting for the unknown unknowns, because your past experiences with them will be nagging in the back of your mind while you're trying to come up with an estimate for some new task. This is especially true if you're estimating work on a project you've worked on before; you'll have a feel for where the trouble spots are and whether or not the task in question is going to get into those spots.

The other trick with this approach is the "more precise estimate after some investigation" bit of the statement. You need to provide some estimate now, buy some investigation time, and commit to another estimate later. Most of the time the second estimate will fall somewhere within the bounds of the first one, but not always, and your manager should be aware of that possibility. But with experience, you'll usually wind up within the original bounds and narrower than the original bounds too, which is quantifiably less uncertainty than before so you can show progress.

<comment><USER5> Company wanted to port an OS to 32-bit (yes I know that dates me). I spent a day, reviewed the code (500 modules), wrote a report - two manyears. Project deferred (ashcanned).

A month later my peer, a senior Engineer with the Company, thought "We should run 32-bit! How long can it take?", checked out the source and started changing files. Gradually people noticed what he was doing, resources got added under the table, finally a year later he had something working. Lots of kudos, smiles, what a hero!

I showed him the report I filed a year ago - and he said "yeah, that's about what I had to do. I'm glad I didn't see that to begin with, I would never have started".

<comment><USER4> Two man-years can easily become one calendar year, if 2-3 people are working fulltime on the project.

Also, "two man-years" isn't a complete estimate using my approach. "One to two man-years" would be a complete estimate, providing a range. Sometimes you really do come in near the bottom of the range, and maybe a month into it if you re-estimated you would have come up with a lower range.

</comment></comment></comment></comment></comment><comment><USER6> The comments here remind me of an old Irish joke where a hopelessly lost tourist asks an old man by the side of the road "Can you tell me how to get to Dublin?". After a few minutes thinking, the man replies "Well, you don't want to start from here".

I doubt 37signals wanted to be in a place where an apparently simple change would involve so much work, but that's where they found themselves. They did what they had to do. There's no point snarking about their starting place without knowing how and why they got there.

<comment><USER7> Is this an old Irish joke? I thought I knew for a fact that it was French!

\- "Pouvez-vous me dire comment aller à Paris"? \- "Ben si j'étais vous je ne partirais pas d'ici!"

Very French in its non-helpful but matter-of-fact way... but maybe the Irish are the same!

<comment><USER6> Your French version feels authentic to me, but then so does the Irish one. I doubt one can say where jokes like these originate. All cultures and languages probably have versions of them.

<comment><USER8> The way I heard the joke in Vermont always involved a tourist asking an old farmer for directions and getting the answer "Well, you can't get there from here."

</comment></comment></comment></comment><comment><USER9> I frequently quote the way Joel phrased this:

 _If you've spent more than 20 minutes of your life writing code, you've probably discovered a good rule of thumb by now: nothing is as simple as it seems._

<http://www.joelonsoftware.com/articles/NothingIsSimple.html>

</comment><comment><USER10> Sounds like they're in need of some hefty normalization. This is the sort of thing that _should_ be handled by changing a single foreign key on each todo / on a single todo list entry; everything else should be pointing to each individual entity, and need no modification.

Unless they're denormalized for optimization purposes? Threaded comments can result in some massively deep queries.

<comment><USER11> > Unless they're denormalized for optimization purposes?

Bingo?

</comment></comment><comment><USER12> Though not directly related to this post, the sentence 'well ... how hard can it be?' is a signature quote from the lead Top Gear presenter.

This almost invariably leads into a challenge that seems easy in theory but the practical execution is always plagued with unforeseen hurdles, crap, unexpected mishaps and other random elements.

It's not that hard to draw parallels between software development and the crazy Top Gear challenges, which is probably a reason that many coders who've never been behind a wheel enjoy watching them.

</comment><comment><USER13> if I were to sum up the counter-reaction to a lot of folks here who think that the claimed difficulty is too high:

You're right, under the right conditions. Namely: small site, early in lifecycle, and a perfectly normalized and non-sharded/non-partitioned database.

But I suspect it's more complicated because:

1\. they have a ton of traffic

2\. they want to maintain a seamlessly perfect UX everywhere

3\. their database is denormalized, sharded and/or partitioned

plus possibly:

4\. it's gotten at least a little crufty with age ( _shrug_ , it happens)

</comment><comment><USER13> Great post but note that the total complexity/LOE of adding that feature would be significantly reduced if (1) it was delivered earlier in the app's lifecycle (less users, simpler code, lower expectations, less/no customers, etc), and/or (2) quality/UX standards were relaxed somewhat.

I agree that even a seemingly simple feature can be hard to deliver, but on the flip side there are dials a developer can turn to adjust his LOE up or down as desired. Tradeoffs as always.

<comment><USER14> > quality/UX standards were relaxed somewhat

Yow.

<comment><USER13> why "yow"?

<comment><USER15> Quality and UX appear to be what 37s is selling; if they skimped on that there'd be nothing left.

</comment></comment></comment></comment><comment><USER16> This would be easy in a graph db. Just move the node and its children come along for the ride.

<comment><USER14> Not exactly. If you look a bit closer, you'll see that this isn't just a strict child, otherwise they might have managed by swapping a foreign key or something. In a graph db, you'd still have to reconnect dangling edges that no longer make sense, like for comments and users. Also, the transaction rollback issue. Which is to say: tanstaafl.

<comment><USER17> Doesn't need to be a strict child when using a _graph_ (not to confuse with hierarchical) database. Not sure what you mean by dangling edges, at least the Neo4j graphdb guarantees that edges are always connected at both ends. It's also ACID compliant so rollbacks are supported. Sure, tanstaafl, but when dealing with data in a graph structure there's much better tools than RDBMS nowadays!

</comment></comment></comment><comment><USER18> <http://www.w3.org/DesignIssues/Axioms#opaque>

</comment><comment><USER19> In the same vein, I highly recommend the article "How many Microsoft employees does it take to change a lightbulb?". This was features in Joel Spolsky's "The Best Software Writing 1" ([http://www.amazon.com/gp/product/1590595009?ie=UTF8&tag=...](http://www.amazon.com/gp/product/1590595009?ie=UTF8&tag=thtaofco0a-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1590595009)).

Link to article: [http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298...](http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx)

<comment><USER20> Nice affiliate link. ;-)</comment></comment>


Game Developers and Porn Stars - <AUTHOR> http://www.killtenrats.com/2009/04/13/game-developers-and-porn-stars/ <comment><USER2> I've got a very close friend that was a game developer at EA for about 4 years. He went through a very similar experience. He eventually burned out, moved back home, went back to school and is now a Chiropractor.

He more or less quit gaming when he was a game developer. After about a year off he returned to gaming and now enjoys the occasional MMORPG or strategy game. He returned to gaming but I don't think he'll ever return to coding.

<comment><USER3> This is an interesting story that is all too common in the games industry. It does seem as though perseverance and 'blind' passion are the most important characteristics of game developers.

I wonder if other roles on game development teams, aside from programming, are nearly as rigorous. Obviously, they are all worked to death, but there seems to be something about furiously debugging for a prolonged crunch mode that sucks the life out of programmers.

During college, I was fortunate enough to take a class from gaming legend Warren Spector (of Deus Ex/Thief/System Shock/Ultimate fame). What impressed me most about him was his sheer, infinite passionate for the games industry. He knew gaming so intimately that I would go so far as to call him a genius. At 50+ years old, he is still going strong in the games industry.

This class brought several guest speakers that were HUGE names in the industry, notably Richard Garriot (Ultima/Tabula Rasa) and Michael Morhaime (Blizzard co-founder). These two guys entered the industry as programmers, but quickly moved onto higher roles in their respective organizations. I think that playing the position of a non-coder is crucial in their career success. There is simply no other industry that can foster the immense inventiveness and creativity required to produce successful games.

</comment></comment><comment><USER4> On the other hand both industries' "indie" sectors seem to treat their workers a lot better. And both industries let you make your first production from your bedroom, armed with very basic tools!

<comment><USER5> Mentioned in the article.

"They are energetic and excited about getting paid to do something they really enjoy (and probably have been doing on a small scale for years without pay). "

"Others think there must be a better, more humane and sustainable way to do this work, and they found their own projects with better conditions. This latter group seems less visible and prosperous, although more outspoken."

</comment></comment><comment><USER6> About 10 years ago my company was supplying a critical component to a major game developer. We showed up at the office the last month of development to help with debugging.

It was a scene out of some psycho's nightmare. 18-21 hour days; 30 people at desks in a room, in virtual lockdown. They looked like the walking dead. The producer was this 5'4" guy wearing storm trooper boots, he'd walk around like Hitler laughing at how fucked up everyone looked, and saying things like "The beatings will continue until morale improves!" No one was laughing.

What was stupid about it is everyone was so burnt they couldn't think straight, kept making simple mistakes. Productivity was probably around 10-15% of peak, if that. It was one of the more depressing things I had ever seen.

All entertainment sectors do this -- they sucker ppl in with glamor and rip them off. It's built into the business model.

</comment><comment><USER7> I'm curious if this is true for all "game developers" or just the sort working at EA and companies that make EA-style games. If you work for Zynga or Playdom, for example, do you have huge crunches and frequent 80 hour weeks? Or is this just the way a few big companies are run.

<comment><USER8> Certainly not all companies. But it is rather common in this industry. And so far I haven't worked on a game yet which didn't at least have some weeks crunch-time before release.

</comment></comment><comment><USER9> The video game industry is great in my opinion, but then again, I work at a startup instead of at a monolithic corporation with over a thousand other employees.

Probably anyone working at a company that large would get burnt out, regardless of industry.

</comment><comment><USER10> Same stuff could be said of professional athletes.

</comment><comment><USER11> Wasn't a member of ID Software an exotic dancer at one point in time?

<comment><USER12> Yeah, I think you're referring either to Stevie Case, a "gaming grrl and Quake champion who became a developer and Playboy model" or "one fellow who took up game programming after he abandoned a shot at the ministry and become an exotic male dancer who went by the stage name Preacher Boy." <http://www.amazon.com/review/R2DHVHM25YIBWO>

</comment></comment><comment><USER13> don't forget investment bankers

<comment><USER14> Well, traders more specifically. You see plenty of 50-year old senior investment bankers -- they're the ones with the client relationships who bring in the big deals. It's pretty rare to see a trader over 40.

<comment><USER15> Corp finance and traders are rival tribes within a bank. The finance people think the traders are vulgar and the traders think the finance people are effete. Lumping them all together as bankers is like lumping developers, sysadmins, qa together as "computer people".

<comment><USER16> Unfortunately most people fail to realize that. In the last few months, bashing _bankers_ has become a socially acceptable norm... and I don't know whether that anger is directed at investment bankers themselves (you know, the ones who do corporate finance) or at anyone who happens to work at an investment bank.

On the cultural aspects of traders, Tom Wolfe wrote a rather biased (not to mention obnoxious) article on that a couple of years ago:

 _"The traders are on the front lines moment by moment, pulling the trigger with only seconds to think about it. They are our kind! They are aggressive real men! Their plain vanilla C.E.O.'s know it too. They will pay a daring, battle-hardened trader $50 million and up per year to keep him from defecting to our pirate fleet. They pay them more than they pay themselves, because they are worth more, because they are real men, because they are willing to fight. What idiot thought up "boards of directors" anyway? My board of directors consists of me, myself, and I. My investors don't have to love me. I don't have to charm them. I have to do one thing and one thing only, make them money."_

[http://www.portfolio.com/executives/features/2007/04/16/The-...](http://www.portfolio.com/executives/features/2007/04/16/The- Pirate-Pose)

</comment></comment></comment></comment><comment><USER17> What illusions do porn stars have?

<comment><USER18> I suspect that the public vastly overestimates entertainment industry earnings due to availability bias. Headlines like "<Star Name> earns $XXM for <movie>" are more common than "relatively unknown supporting actor earns enough to maintain SAG membership."

Likewise, young women probably perceive the porn industry to be much more lucrative than it actually is. I've read that they get paid between $500 and $2K per scene. While that sounds amazing to an eighteen year-old working at McDonald's, it probably translates into $100K annually for three or four years until younger talent takes their places.

<comment><USER19> 100k annually for three or four years is like 400k. That's ten years worth of a decent middle class salary, which is what most careers are worth, except it's front-loaded so you can generally invest it and make more in the long run. I would not snort at that kind of income.

<comment><USER20> I suspect the kind of person that does porn at 18 is not likely to prudently invest the money they make while young.

<comment><USER21> And programmers are different? I'm amazed at how much my co-workers spend on stupid gadgetry and personal entertainment.

</comment></comment></comment></comment></comment><comment><USER22> This must be the reason that the large game companies such as EA are completely lack of innovation. They turn out the same games year in and year out with only slightly better graphics, ai, etc...

<comment><USER18> Do the people who write the underlying engines/frameworks (I know little of game development) have it better than those assigned to particular titles?

<comment><USER23> a large majority of those ship with a AAAish title (I guess in part eating your own dogfood) - think Lawrence World or Basecamp for the Web framework discussion... We're talking games like Quake X, Unreal (Tournament) Y, etc

So they probably hit the same kind of crunch as well.

</comment></comment></comment><comment><USER24> This article makes me wonder if the web industry is like the local strip club.

<comment><USER18> I believe that strippers' earnings are somewhat proportionate to hours worked.</comment></comment>


Apple Releases Safari Technology Preview 26 with WebGPU Prototype - <AUTHOR> https://www.macrumors.com/2017/03/22/apple-releases-safari-technology-preview-26/ <comment><AUTHOR> The release notes are available here [1]. I couldn't submit that link directly, so I linked to the MacRumors' article instead.

[1] [https://developer.apple.com/safari/technology- preview/releas...](https://developer.apple.com/safari/technology- preview/release-notes/)</comment>


How We Failed at OpenStack - <AUTHOR> https://www.packet.net/blog/how-we-failed-at-openstack <comment><USER2> Doesn't surprise me the slightest to be honest. Having worked on a customized fork of OpenStack that used a pure L3 networking model I know that you are set for pain the moment you don't want to run everything on a single Ethernet segment.

It doens't help that the Neutron data-model at the time that I was working on in (say 12 months ago or so) was terrible and basically impossible to scale/make to perform.

Inevitably you were then stuck with the deprecated and janky nova-network interface. Which while efficient and fast was also old and missing tons of stuff - meaning more monkey patching and janking around. Not to mention the fact that because of it's deprecation many completely ridiculous bugs befell it in later releases. (Grizzly and onwards basically)

TBH I am so disillusioned with the project I hope I don't have to work in or around it again.

<comment><USER3> > TBH I am so disillusioned with the project I hope I don't have to work in or > around it again.

You're not the first I've heard this from, nor do I suspect the last.

The problem isn't that the code is bad as much as it is that the climate often makes it impossible to fix it. Review queues are weeks or months long. The article makes a good point about the necessary man hours to work on OpenStack. I've seen code removed not because it didn't have a maintainer, but because 200 lines of code didn't have 3-5 full time developers. Insanity persists and money talks.

Looking back, I'd say that OpenStack Nova in the beginning was never this bad. It may not have been the best thing ever, because it wasn't, but no code needs to be terribly great in the beginning. The beginning of a project needs good process more than it needs good code, and OpenStack didn't establish this well enough, early enough.

OpenStack never had a solid, centralized architectural vision. Anyone that attempted to contribute architecturally was essentially ejected. Those that flushed millions into controlling the process and millions more into building adhoc features got their way. I mistakenly advocated early for wrangling control from Rackspace. The increased influence gained by individual contributors was quickly dwarfed by large corporate influences.

I'm still involved with OpenStack, but far less than I had been in the past. Mostly, I prefer to see myself peripherally involved where I might improve the lives of those trapped in that ecosystem, either to help them deal with the pains they've inflicted upon themselves, or to escape them entirely.

<comment><USER4> _The problem isn 't that the code is bad as much as it is that the climate often makes it impossible to fix it._

Lots of the code isn't great either.

</comment></comment></comment><comment><USER5> Not sure if people _know_ about Apache CloudStack or not, it has all those IaaS feature and it just works with various basic to advance networking models.

<comment><USER6> Apparently CloudStack "lost" to OpenStack ( see: [http://www.infoworld.com/article/2608995/openstack/cloudstac...](http://www.infoworld.com/article/2608995/openstack/cloudstack --losing-to-openstack--takes-its-ball-and-goes-home.html) ). I've also heard this sentiment in my admittedly openstack biased circles.

That said, I'm not suggesting it should not be considered.

<comment><USER4> It lost out in getting _vendor_ support from lots of different big vendors. OTOH, many hosting environments find it more useful. (It used to be a Citrix product which might explain the more unified architecture it has).

</comment></comment></comment><comment><USER7> I agree with the Author's observation that there are a lot of vendor specific changes on top of openstack before making it production ready. This struck me as slightly alarming when I first started working with the project: my previous experience with FOSS had been linux, GCC and the like, which were good to go from the start. To his credit, it does seem like the author made a serious effort to understand how to get Neutron to do what he wanted...

I'm guessing that a lot of people make the same mistake of thinking openstack is just as easy as linux to get running. Its really not. But it does provide 95% of the groundwork to get you started; often that remaining 5% is either your secret sauce or security overheads. And unfortunately, the details of how to do _that_ are not open to the public...yet.

Also, a the slow pace of adding changes to openstack makes many projects add their changes to their custom patches and once its working there really isn't much incentive to push it upstream.

</comment><comment><USER8> Sounds like these guys are doubling down on the IAAS model, 'premium bare metal'? Certainly there are a lot of people who'd like to run on bare metal, with a more configurable network, but how realistic is it at this time?

>>You see, physical switch operating systems leave a lot to be desired in terms of supporting modern automation and API interaction (Juniper's forthcoming 14.2 JUNOS updates offer some refreshing REST API's!).

This. Network hardware vendors have no incentive to make their devices more easily automated, and in fact face disincentive not to.

Doe anyone remember the excitement and promise around Google App engine when it was first announced, and before they changed the pricing model to per instance? The ability to put your app on the cloud, and scale up to the free tier, then out from the free tier on a paid plan if that's what you needed.

That model entirely disappeared. I miss it. Is anyone doing that now?

<comment><USER9> >> >> You see, physical switch operating systems leave a lot to be desired in terms of supporting modern automation and API interaction (Juniper's forthcoming 14.2 JUNOS updates offer some refreshing REST API's!).

>> This. Network hardware vendors have no incentive to make their devices more easily automated, and in fact face disincentive not to.

There is actually a relatively established roadmap for the solution to this in "bare metal" / "white box" switches that essentially just talk OpenFlow to a controller. Google moved their entire international internal backbone (more traffic than public facing) to this model[1].

The issue at the moment is that there isn't lots of OS options and subsequently very little hardware support. Google developed their own hardware (despite preferring to have bought it[2]) and my understanding is they wrote their own software too.

[1] [http://www.opennetsummit.org/archives/apr12/hoelzle-tue- open...](http://www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf) [2] [http://youtu.be/VLHJUfgxEO4?t=39m20s](http://youtu.be/VLHJUfgxEO4?t=39m20s)

<comment><USER10> +1, talking about rest endpoints hosted by junos is missing the forest for the trees. Protocols like Openflow, and whatever the contrail version was called, seems o be where network automation is headed. Centralized state & modelling and pushing specific paths/updates out to the edge.

With regards to "bare metal" virtualization I'd expect to see a lot more in the next 12-18 months. On the network you need dynamic path configuration and traffic encapsulation/isolation. That should be "openflow" and vxlan/nvgre. On the host hardware youll want io virtualization (sr/mr iov) and possibly hardware encap as well. Substantial progress is being made on both fronts.

Edit: although its great to have two encap options I think theyre incomplete at best. All of the hard work has been punted to the centralized controllers and the rfcs have nothing useful to contribute there. Some of the rfc behavior is also insane/laughable; multicast for broadcast and mac/tunnel endpoint discovery ORLY? Ill be very surprised if there are any large vxlan/nvgre deployments which arent bespoke.

<comment><USER9> The opportunity extends beyond support for x86 devices in that more traditional hardware switches etc. should also work with openflow.

I've found there's lots of OSS around the controller and virtual switches for testing/lab but the only serious openflow agent designed for hardware switches I've found is Big Switch's Indigo[1] it has very limited hardware support.

I see experimental support in OpenWRT - this is very interesting as it opens up a shed load of hardware options.

[1] [http://www.projectfloodlight.org/indigo/](http://www.projectfloodlight.org/indigo/)

</comment></comment></comment></comment><comment><USER11> This seems to be more of a lesson on the failures of community building vs. secrecy in the face of a presumed pile of money and the resulting vendor politics, than "OpenStack sucks".

An OSS project isn't really supposed to be about "I can freeload on the works of others for some investment in comprehension and customization", which is how I felt the author framed his situation at times.

The underlying failure seems to be that the author decided it was easier to maintain his own proprietary platform than modify OpenStack for their needs and contributing back to the community. This would lead to others to pick up their stuff down the road and potentially reducing the maintenance burden (at the expense of exposing any secret sauce you feel you might have).

This deeper failure is In the incentives for Rackspace to withhold key commits on Ironic from the community because they feel it is secret sauce. (I am taking the OP's version of the tale at face value). They're one of the flagship supporters of OpenStack, and their behavior is perceptably a big reason for its failures to date.

The limitations of Neurtron without a product like VMware NSX underneath are well known. Production grade virtual networking at scale is hard and also mostly a secret sauce (for now).

OpenStack seems to effectively have become the OMG and CORBA 1.0 with a reference implementation - it's cloud vendor kabuki instead of distributed objects square dancing. You need vendor help to get going, and the portability is very limited, you'll get some value out of what's been done but at great effort. It seems to also be a useful commons for network and storage vendors to help drive interperability with the side modules (Cinder and Neutron). If anything, OpenStack is how the industry is desperately brute-force learning what Amazon Web Services has accomplished before they swallow the universe, which is valuable but messy.

OpenStack seems the only "I want to run a general purpose cloud" game in town today - CloudStack exists but doesn't seem to have a lot of momentum. Google, Azure and Digital Ocean are the only competitors to AWS of note and they don't open source their stuff. CoreOS on PXE or Ubuntu MaaS might work but needs a much more mature cluster schedulers, network and volume management. Or perhaps the real next generation will be "none of the above".

<comment><USER12> > This deeper failure is In the incentives for Rackspace to withhold key > commits on Ironic from the community because they feel it is secret sauce. > (I am taking the OP's version of the tale at face value). They're one of the > flagship supporters of OpenStack, and their behavior is perceptably a big > reason for its failures to date.

I'm an Ironic core reviewer and work on OnMetal at Rackspace.

At Rackspace, we run ahead of Ironic trunk. It's true that we haven't been super vigilant about upstreaming our patches into Ironic; this is not because it's "secret sauce", not because we don't care. Priorities are hard, both upstream and downstream.

OpenStack moves slowly compared to a team developing proprietary software. This is a well-known fact. We do our best to upstream our patches as quickly as the project allows, but they often need to be improved to work with other hardware/drivers/etc.

For example, when we launched in July, we already had support for "cleaning" a server - erasing disks, flashing firmware, etc. The "spec" for the new feature was first posted upstream June 25, 2014.[0] This spec finally landed last January 16, 2015.

Our work on improving network support in Ironic has been similar; the project hasn't been ready for it (again, priorities). It's been done in the open[1], but the code is not in Ironic trunk yet.

We've been extremely open about what we're doing since we joined the Ironic project almost a year ago; I'm curious which patches the article has in mind.

As an Ironic developer, this article bums me out a bit, but it's a good pointer as to what we're doing poorly. /me starts writing better docs

[0] [https://review.openstack.org/#/c/102685/](https://review.openstack.org/#/c/102685/) [1] [https://etherpad.openstack.org/p/ironic-neutron- bonding](https://etherpad.openstack.org/p/ironic-neutron-bonding)

<comment><USER13> I just wanted to chime in here to say that although there were several situations where our questions couldn't be answered, we probably wouldn't have made it as far with our testing if it wasn't for the answers that _were_ received from the openstack ironic developers. I should also point out that I've always found the openstack ironic devs to be kind and professional. So be it as it may, it is unfortunate that there are some conflicting priorities but I certainly do not blame the devs.

</comment></comment></comment><comment><USER14> My experience agrees with the general tone of the article (although I didn't dig as deep into the code as OP). I implemented an OpenStack private cloud for testing/QA purposes but never felt comfortable enough with it to migrate production (this was Icehouse, so pretty recent).

It was too easy to break core functionality--for example, I literally never saw resizing an instance work properly. It does this crazy hack where under the hood it SCPs the VM image to another host and then tries to bring it up. It could have been a quirk of our installation but it would break every time. I saw similar breakage with Cinder operations where volumes would get "stuck" on VMs. Again, it could be a bad installation but it goes to show you how easy it is to break OpenStack if you aren't an expert in the codebase.

My current thinking is that a container-centric (as opposed to VM-centric) infrastructure is the way to go--that way I can just throw CoreOS or whatever on the bare metal nodes and migrate containers as needed.

<comment><USER15> Sure, container-centric is great if you are running containers. Until it is shown that containers are actually secure, people are going to push for virtualization.

</comment></comment><comment><USER16> The author writes:

 _" As we finalize our installation setup for CoreOS this next week (after plowing through Ubuntu, Debian and CentOS)"_

Pity he doesn't elaborate on that. I understand that CoreOS is his choice, but it would be nice to know why the other distros aren't.

<comment><USER17> Our guys tried CentOS for awhile with OpenStack, but gave up because so much of it is clearly maintained with Ubuntu in mind. So they switched to Ubuntu and things have been mostly smooth sailing since then.

<comment><USER18> Same for us. So much of the documentation is really only for Ubuntu, and you quickly run into gotchas where you have to decide.

Do I want to work out and fix all the issues to get this distro working, or do I want it to work and move on to the other gotchas?

</comment></comment></comment><comment><USER19> Can someone explain 'bare metal' to me? Is it a better hypervisor or something? Why would it be better than all development effort put into something like linux? Doesn't the linux kernel run on 'bare metal'?

A fellow developer tried to get me into openstack a little over three years ago, and when I looked, it was far too enterprise for my tastes, but I care more about code than the devops and managing servers.

<comment><USER20> Bare metal just means not virtualized. There's no hypervisor between the OS and the hardware (the hardware is made of metal, therefore "bare metal"). If you buy a computer with Windows on it, Windows is running on bare metal. Hypervisors run on bare metal.

So yeah, as you suggested, if you install Linux on your computer, the Linux Kernel is running on the bare metal.

<comment><USER21> So really, this is still virtualisation - but with less overhead.

</comment></comment></comment><comment><USER6> It would be cool if the author could elaborate on this conversation: "As the conversation developed, I eventually agreed that many of the public cloud services were not user friendly and had an overly high barrier to usage"

...as I read through the article is sounds like it was probably around bare- metal needs - still, elaboration would be nice here :)

</comment><comment><USER18> I am doing this same work for the company I work for. I think it's going well, but it's taken far longer than any estimates I have planned.

The Ironic guys are amazing, really great people to work with. The guys in IRC are good at working with us.

Just hope we can provide some value to the project as well to return the favor.

<comment><USER22> @AndyNemmity I totally agree - the Ironic guys (particularly jroll) are awesome and were very helpful.

</comment></comment><comment><USER23> Shouldn't take more than an evening for somebody experienced with hosting to pick up these red flags reading through the OpenStack documenation/source.

From what I recall the documentation left a ton to be desired. Just trying to figure out how Neutron and their "VPC" equivalent was supposed to be implemented left more questions than answers :|

<comment><USER24> Yeah, I looked at openstack for a few days - including a small test deployment, and came away with "not for a few more years"

</comment></comment><comment><USER25> > Premium Bare Metal

Given that's the offering, it doesn't surprise me a bit they didn't go with OpenStack. That said, I guess they think running containers on bare metal is a better way to roll.

<comment><USER26> It would be, if the docker containers were actually root safe. Currently, youll probably have to rent an entire physical machine to run your containers on, which will be fast, but not necessarily great for packet as they grow.

Openstack really isnt appropriate for this type of scenario, unless their original goal was to use KVM machines to add some extra security / multi- tenancy.

<comment><USER3> They were looking to use Ironic, which is specifically built for renting entire physical machines. I agree, however, that contributing and working upstream in OpenStack is challenging. I do not doubt that they would find it easier to build new infrastructure than contribute to OpenStack.

OpenStack no longer behaves like a nimble startup and may no longer be the right option for someone looking for a quick, iterative development process. I'd question if any startup should really be a consumer of OpenStack at this point.

<comment><USER27> Eric, I think that is bit of a leap. If we look back to the mission statement, it still fulfills that role IMO. Ironic is without doubt the immature stepchild, which to me really only makes sense if you wanted to do visualization - but also offer bare metal under the same API.

<comment><USER3> To put it another way, I question if any startup should be using OpenStack today if OpenStack does not immediately solve the needs that startup expects to solve in the future. That's especially true for DIY. I'm speaking as consumers of OpenStack, of course, not for companies building value on it.

If OpenStack doesn't solve the startup's future needs right now, the startup's future need will come sooner than the features needed in OpenStack. Contributing upstream will have too great an opportunity cost. The only legitimate options for such companies are not to use OpenStack or maintain their own fork.

Right now, at the rate of innovation and improvement currently in OpenStack and the processes necessary for participating in the community, I'd argue that if a startup _consuming_ OpenStack has resources to dedicate toward upstream development and baby-sitting that process, that they're either A) Not a startup, or B) a failing startup.

<comment><USER28> s/OpenStack/customLinuxKernel/

No startup should be rolling their own cloud, any more than they should be putting together their own Linux kernel. Go public, or if you MUST be on your own metal, use a turnkey solution like Metacloud or Nebula (and let them manage it for you).</comment></comment></comment></comment></comment></comment>


Shekhar Kapur Bets Big on Asia as Global Entertainment Hub - <AUTHOR> http://knowledge.wharton.upenn.edu/india/article.cfm?articleid=4211 Asian Media (including Bollywood) will rule the entertainment domain ...
<comment><AUTHOR> though there are funds being created, this is the only industry which is kind of close to new entrant, e.g. any independent artist can only expect thousand miracles to happen to succeed !!!</comment>


Flubber: smoother shape animations in JavaScript - <AUTHOR> https://github.com/veltman/flubber <comment><USER2> Really enjoyed Noah's OpenVisConf 2017 talk which covered a lot of the motivation and prior art behind the development of the library:

[https://www.youtube.com/watch?v=PLc1y-gim_0](https://www.youtube.com/watch?v=PLc1y-gim_0)

(Link is in the README file on GitHub too, but easy to miss)</comment>


First mobile(iOS) app submitted to the app store for review - <AUTHOR> http://captaindanko.blogspot.com/2015/08/first-mobileios-app-submitted-to-app.html <comment><USER2> > having a test plan before starting development can be so very helpful, > especially if development stretches over a substantial period of time and > new features are added during development.

I think this could also be restated as, have your initial use case well defined. Test plans aren't as good as users and/or very targeted features. In fact, the test plan actually comes from those use cases.</comment>


Started freelancing last month and this service has been invaluable - <AUTHOR> http://www.mycpohq.com

<comment><USER2> Oh well, won't be a lot of use to you (right) now.

<http://downforeveryoneorjustme.com/www.mycpohq.com>

<comment><AUTHOR> Sheesh, do something nice for some body... It better get back online soon!

</comment></comment><comment><USER3> this link should come with a disclaimer of sorts. so this guy started freelancing last month and already a complex app for billing + time management has been invaluable? In one month, even word + excel (or whatever office suit you use) is invaluable.

<comment><USER4> It really shouldn't matter what you use or how long you've been using it for if it works for you.

I freelance and find these types of billing/time management applications to provide a service that is invaluable to me. I can more accurately bill clients and easily keep track of the projects I'm working on because they tend to have things like built-in time trackers and integration with popular apps that perform other functions (e.g. project management) that excel doesn't. There is no way that I can do this without a lot more effort with a simple office suite. Alternatively, if I did use something like excel to keep track of these things for a month or two, I've now got to slowly migrate to some other alternative or find a way to input that kind of data into my new choice of app, and that's time wasted that didn't need to be. If you know you're going to do this, you may as well start with what you're going to use. I've switched apps mid-project before, and it was a huge pain to the point that the next time I switched to another app, I was stuck using both the old and the new until projects were finished, just because of the migration hassle. (For the record, the first one was a billing/invoicing one, second was my business to- do.)

On the flip side, I know people that keep track of these things in spreadsheets, they've done this for years, and that's their choice because they like it that way. I can't stand it. Whatever works for you.</comment></comment>


Stacked Diffs versus Pull Requests - <AUTHOR> https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/ <comment><USER2> The idea of "stacked diffs" looks like a good one, but this article doesn't do a great job of presenting them. It's way too long for the actual claims it makes. It combines two things: Working on a single branch and reviewing commits instead of branches.

Reviewing commits instead of branches makes a lot of sense, and would definitely result in a cleaner history than pull requests seem to do in practice.

The article also makes the claim "They'll get reviewed in some order and committed in some order". If the changes in the second commit depend on the first commit, that's just as false as with pull requests that depend on each other.

The article names one concrete downside of the use of many branches: If one branch depends on the changes in another branch that's not in master yet, you end up with an annoying bunch of rebases or ugly merges. Committing everything to a single branch turns that into a single rebase.

\---

So that's the content. Then there are the case studies, which are odd. Charlie the free spirited hacker magically turns from someone who...

> starts the day by branching master and spamming the branch with five commits > that are only vaguely related.

into someone who

> blasts out five commits and five Diffs back to back. Each one addresses > something specific.

All thanks to the magic of Stacked Diffs.

<comment><USER3> You are missing the subtle and hard to explain point that he tried to illustrate with the Tale of the Tree Icon. It's that our tools and their defaults shape the way we work. I watched a team switch from branches to stacked diffs (mercurial queues, way back in the day) and it was almost exactly how this article describes.

<comment><USER4> It's the tools and their defaults that leads me to my biggest criticism with the article. On darcs something like "stacked diffs" makes a ton of sense because the UI was built for it from top down, and cherry-picking is _magic_ (when it works), including that it tracks your dependencies between commits/patches for you.

In git, we have a dependency tracker in the DAG, but it requires the work of branching to make use of its power. In git, cherry-picking is a footgun with all sorts of potential problems. I've seen far too much work lost to bad rebases to trust junior developers with cherry-picking and rebase-heavy workflows in git. (Yes, I realize that a lot of people disagree and a lot of people use very heavy rebase workflows, this is just my opinion that in general rebase workflows are more danger than I want in my source control, as the resident source control guru on many of the teams I've worked on.)

Pull Requests actually work really well with this dependency tracking. If I create a PR for the database changes, a PR for the REST API changes, and a PR for the UI work that depends on both of the previous two, and all of those PRs are well merged branches (no rebases) using the DAG to encode dependencies, my reviewers have the option to review those in any order. If they review the two smaller subset PRs first, as that content merges to master most good PR tools simplify the remaining UI PR to just the UI stuff not in master. If they review and merge everything all at once in the giant UI change PR, then most good PR tools will automatically mark the other two PRs as merged and complete, no work needed for individual review of the two subset PRs. The choice there is left to the reviewers, and the tools just do the right thing, whatever the preference the reviewers have.

<comment><USER5> What PR tools are you referring to? We just use github pull requests, but stacking PRs seems impossible because merging the parent PR doesn't seem to update the children PRs automatically.

<comment><USER4> I've used GitHub, Azure Repos (nee VSTS nee VSOnline), and Bitbucket (Cloud and Server), and I've seen some version of support for it in all of them.

</comment></comment></comment></comment></comment><comment><USER6> This is a great model that scales very well to the largest projects and most complicated refactors. In fact, it _forces_ you to think about your refactors differently, and that is actually great. You learn to boil the ocean incrementally more.

We got the decentralized workflows alongside concepts like pull requests... but there's no real reason why you can't use your decentralized workflows with trunk based development. The secret, is combining the two: decentralized workflow for local development, with modern CI and code review, that all lead into the trunk.

I've personally been veering toward this model for a while, and it's also somewhat similar to what Google is doing[1], and it works great across a lot of different circumstances.

[1]: [https://cacm.acm.org/magazines/2016/7/204032-why-google- stor...](https://cacm.acm.org/magazines/2016/7/204032-why-google-stores- billions-of-lines-of-code-in-a-single-repository/)

</comment><comment><USER7> Isn't this basically how gerrit is supposed to be used? At least that's how we use it (but it's a very small team so anything would work I guess).

You work on master, you rebase -i your commits to make them nice to review, you push them to gerrit, someone reviews them and pushes them to master or returns with stuff to fix. You usually have a few commits on top of remote master in your local master, and when any of them is pushed to remote master from gerrit you just git fetch && git rebase.

<comment><USER8> Yes, the Phabricator and Gerrit workflows are very similar.

It's basically the same workflow the Linux kernel uses, with Phabricator or Gerrit taking the place of git format-patch and git apply-patch.

</comment></comment><comment><USER9> This is silly. I use Phabricator and I don't commit my changes directly to `master`. I always make a branch, exactly the same as you would for pull requests. And I have multiple commits on that branch.

Why? Firstly it means I can still pull master and rebase my changes to update them fairly easily. Secondly it means I can work on more than one thing at a time (who only ever has one task in progress?), thirdly it means I can reorganise my commits easier (`git rebase -i master`), and finally having a change split into several commits can make code review easier.

As far as I can tell the only significant difference between these two approaches is that with `arc` the history in the repository ends up nice and linear, without loads of branches.

<comment><USER8> I also use Phabricator like you do, but the author makes a compelling argument to use a stack of master commits rather than individual branches.

> _Firstly it means I can still pull master and rebase my changes to update > them fairly easily._

Like the author says, you can do this, but it's easier when your commits are stacked on master (you only do one rebase vs. rebasing each of your branches).

> _Secondly it means I can work on more than one thing at a time (who only > ever has one task in progress?)_

Read the article, the author uses interactive rebases to edit commits.

> _finally having a change split into several commits can make code review > easier_

How? The reviewer doesn't see those commits, unless you submit them as separate revisions, in which case they wouldn't be on the same branch.

> _As far as I can tell the only significant difference between these two > approaches is that with `arc` the history in the repository ends up nice and > linear, without loads of branches._

Either approach would have the same result, it's all about how things are organized in your local repository.

I'm not fully convinced (the tooling isn't exactly built for this workflow and you lose "arc feature"), but I like the idea.

</comment></comment><comment><USER10> > How do you git bisect a codebase where every 6th commit doesn't build > because it was jammed into the middle of a Pull Request?

This I think is the main problem with pull requests. A better default would be squashing the commits into a single one after review.

<comment><USER11> I have always been of the mind that every commit should be a working state. My coworkers who often commit with the message "WIP" disagree. I doubt I'll ever sell them on it.

<comment><USER8> Yeah...WIP commits are fine _in your local feature branch_. I wouldn't ever want to see a WIP commit in my origin/master.

</comment></comment></comment><comment><USER12> I think I agree with what the author is saying, by and large, but it doesn't matter: if it's a mental model that works for you, you can live in the "stacked diffs" world right up until you need to "curate" all your commits into something that can be considered for incorporation into the parent project.

Then you still need to make a branch, put all the related commits into it in order, and adequately test that branch before sumbitting it.

At that point, if changes are requested, you can make a choice about whether to work by rebasing that branch, or work on your "master" branch and then re- curate those commits. Now, working in the stacked diffs world seems like more work, but you do you.

A place I disagree with the author is about rebasing frequently onto master. Assume you are working in a healthy project with frequent and largely bug-free releases, but occasional trouble during development cycles where tests end up red for awhile despite everyone's best efforts. In this situation, you are better off starting your work _from a quality release tag with no red_ ; occasionally you'll end up dealing with more merge conflicts when you're ready to merge the branch, but IMO not so much that you don't derive benefit from avoiding all those rebases onto a new upstream revision that just might be totally bonkers.

If you do this, you should still validate that your branch, merged with or rebased onto master, doesn't make any new test failures or interact destructively with other work; deferring this to the end DOES have a cost, but in my experience it is outweighed by the benefits.

(And if you're in one of those now-rare projects where it's the norm to be making point releases of one or more old releases, PLUS having new development on a master branch, basing your branch at the right place means you can merge it into the old releases with ease...)

<comment><USER13> Hm, I thought the idea is that the only way something will land in master is if it reviews OK and CI passes all the tests on top of the current master?

<comment><USER14> "on top of the current master" is limiting: how do you handle concurrency? I.e. two developers kicking tests on their PR on top of current master, everything green, but they merge and the result of their merge is not building (or passing tests) anymore.

<comment><USER15> Most CI systems serialize builds on master, at least at the very end of the build pipeline. That can slow things down, but, if combined with a decently fast/thought-through build process with tears, I think the benefits of not risking untested states outweigh the costs.

<comment><USER14> This is not about serializing builds on master, but builds on the PR before they get merged on master. If you have a few hours of test plans, you can't serialize every PR one after each other.

<comment><USER15> If your testing is time consuming to the point that you can only test on your PRs and never on what master would be after each one merges, then you have to choose between somehow forcing PR authors to serialize their merges somehow (external convention or tooling or something) or not testing the code that will actually be released. The latter isn't always the wrong choice, though.

</comment></comment></comment></comment></comment></comment><comment><USER16> So basically the author proposes replacing Pull Requests with "Cherry-Pick Requests", where each commit is a single reviewable unit (replacing separate branches with the PR model), the local master branch represents a list of unreviewed commits, and the remote master branch represents reviewed, "merged" commits.

It's an interesting idea, but even after reading this article I'm still not convinced it offers any serious advantages over a more traditional workflow. It also has the downside of requiring extensive use of more advanced features like interactive rebasing. (Which I personally have no issue with, but seems like a potential nightmare for developers who aren't as experienced with git.)

<comment><USER3> " It also has the downside of requiring extensive use of more advanced features like interactive rebasing."

This is true. In the early days of mercurial (back before it was clear that git was winning the popularity contest) there was an extension called Mercurial Queues[1] that made it really easy to work this way. The downsides were: it didn't handle conflicts well, and it could totally destroy your work if you weren't careful. Since then someone has written the Evolve extension which is Mercurial Queues done right. That, sadly, came about after git had "won" the popularity contest.

1\. Best explanation of Mercurial Queues: [http://stevelosh.com/blog/2010/08/a-git-users-guide-to- mercu...](http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial- queues/)

</comment></comment><comment><USER17> I think GitHub's great, and I'm mostly okay with having to rely on it heavily at my day job, but I dislike how code reviews + PRs are necessarily tied to branches.

What are the chances of GitHub introducing stacked diffs (or a similar abstraction) as an option? It'd be great to try out this workflow on a non- trivial project, but it seems like a hard sell organizationally when it involves migrating to and supporting a completely different tool like Phabricator or Gerrit.

<comment><USER8> You _can_ do stacked diffs on GitHub by always using squash merges and rebasing on top of master, and it's a great way to get started.

It's just a lot nicer with the extra tooling on top that Phabricator and Gerrit provide (dependencies, command line tools, and so on).

<comment><USER18> If you squash merge you just lost all the small commits that do one thing well that you spent time creating, unless you review them one by one. Bleh.

<comment><USER8> That's the entire point of a stacked diff workflow - you would submit smaller PRs which are the equivalent of one commit.

</comment></comment></comment></comment><comment><USER19> So basically what Gerrit offers as the "cherry-pick" submit type? You work on the master branch, then push commits as changesets to Gerrit. After review they are cherry-picked by the system onto the target (master) branch, in whatever order they happened to be reviewed. Or am I missing something?

</comment><comment><USER20> How does this workflow work when there are 3 commits that need to be applied in order (A, B, and C), when C gets approved from a code-review standpoint before A and B?

<comment><USER21> You are prevented from merging commits at the top of the stack until the commits below are accepted.

The advantage is that each commit can be reviewed separately. You cannot achieve this with pulled requests as far as I know. I often see people creating a pull request and writing "this depends on PR #1233", the second PR is unreviewable because it contains changes from. The first PR. So the first PR has to merged first... It's a mess. But maybe I am just missing a big part of the PR workflow that solves this problem.

<comment><USER4> If the branches are properly merged so that the dependency is represented in the git DAG, most good PR tools just handle this correctly: if you merge the dependent PR first the dependee updates to show the commits as already merged and "simplify" their diff views appropriately; if you merge the dependee PR first, the dependent PR simply gets marked as completed/merged for you.

I find it is still useful to include helpful hints like "this PR includes all of PR #1234, if you prefer to review a piece at a time", but that's for the reviewers' sake, not the tools'.

<comment><USER21> Yes, that's nice. But the problem is that these are still shown as separate PRs, GitHub for example doesn't tie these together unlike Phabricator.

<comment><USER4> GitHub has enough information that it could surface that better. It's a useful feature request.

</comment></comment></comment></comment></comment><comment><USER22> In the PR model, we can easily hook up a build system to automatically trigger builds on remote branches. How would that fit into this?

<comment><USER23> And that can be (and is) done with the stacked diffs model as well. CI is orthogonal to whether you use the PR model of the stacked diffs model.

<comment><USER16> But what commit do you run the CI against? If you run it against a commit that's stacked on top of 3-4 other unreviewed changes, then the CI will include errors from all those other commits, not just yours.

<comment><USER21> You don't stack against random commits. Only commits that have passed tests before and so are on master, or your own commits.

<comment><USER16> That's not what the article says:

> Yang sees that the Diff for the "fix" is out for review. Yang uses the > Phabricator command line tool to patch that commit on top of master. This > means that it's not a branch. It's just a throwaway local commit. Yang then > starts working on the first change. Yang submits a Diff for review from the > command line. Later, the "fix" has changed, so Yang drops the patch of the > old version from the Git history and patches in the updated one via > interactive rebase.

</comment></comment></comment></comment></comment><comment><USER24> It seems that topgit can be used to achieve this workflow. The beauty of it is that it is built on top of git, so it has the familiar mechanics internally while providing a new way of doing patch series / stacked diffs.

</comment><comment><USER25> Can someone explain why this is better than branch, commit and rebase from master if needed, then submit the pull request?

<comment><USER26> The case studies articulate the difference pretty well.

</comment></comment><comment><USER27> This is best workflow I've used so far (but usually I had separate branch for really unrelated changes).

</comment><comment><USER28> Is this similar to Mercurial Queues?

<comment><USER3> Very much so. The difference is that it uses regular git commits, and you push and pop by doing interactive rebase.

Sometimes I really miss mq

</comment></comment><comment><USER29> This seems like a good approach. However, it's unrealistic that my team is going to move off GitHub. Is there any way I can do something like this locally, but then have it fit into a GitHub PR flow?

</comment><comment><USER30> This is very long and i'm tired, is there a more condensed resource?

<comment><USER31> I think the tl;dr is "stacked diffs require running different commands than git pull --rebase"

The author complains about wasting time branching and merging, but other examples at the end still have the same number of operations and still hit the same merge conflicts.

They make the point of how dependant work requires multiple branches but I feel it's a workflow constraint, or a technical one. It can be easily avoided by creating branches as late as possible! Usually, when I'm working on a problem that requires multiple merges, I

1\. Create a branch to fix the problem

2\. Work on it

3\. Rebase it so I can merge the first few commits

4\. Push just those commits with a different branch name

5\. Get it reviewed

6\. a. Merge the reviewed branch into master and rebase the problem branch on top of master

6\. b. Update the branch under review with feedback fixes, push it & update the review & rebase the problem branch onto the updated branch under review & go back to 5

7\. Go back to 2

Just don't do what I end up doing on personal projects and let 6 months go past between 2 and 3

<comment><USER32> As the article pointed out, the problem here is you can't easily deal with multiple branches stacking on each other.

You may argue that it is possible to put all these changes into one branch, but "asking 6 people to review a 500+ lines change, in which only ~100 lines is meaningful for each reviewer" is not a nice thing to do and it obviously delays the code review process.

<comment><USER31> I feel like my workflow address that exactly: by making a separate branch per reviewable change from the base of the problem branch.

</comment></comment></comment></comment><comment><USER3> Another code review tool that lets you work this way is Review Board: [https://www.reviewboard.org/](https://www.reviewboard.org/)

</comment><comment><USER33> Interesting, does anyone know of any scripts to allow you to use stacked diffs locally when your team is using tools based around pull requests (i.e. GitHub)?

</comment><comment><USER22> We recently shifted from Gerrit to Bitbucket. I don't miss Gerrit. Perhaps I am missing something.</comment>


How much destruction is needed for us to take climate change seriously? - <AUTHOR> https://www.theguardian.com/commentisfree/2019/sep/03/how-much-destruction-is-needed-for-us-to-take-climate-change-seriously <comment><USER2> probably when whole cities die from extreme heat. climate refugees emmigrating because whole countries are not habitable for humans. inability to produce revenue because every one is too hot or too interested in basic survival to work for paltries such as a paycheck

<comment><USER3> even the most pessimistic IPCC predictions don't go that far</comment></comment>


Why I'm Not a React Native Developer - <AUTHOR> https://arielelkin.github.io/articles/why-im-not-a-react-native-developer.html <comment><AUTHOR> OP here. I'm posting this for the potential discussion, not because I agree with the article. He does make some valid points, although a large part of the article is (somewhat valid!) complaints about JavaScript. So far I've been really enjoying React Native but I am curious to know what, if any, brick walls people have hit when working with it.</comment>


Ask HN: Quick Help with Investment Competition - <AUTHOR>

Hi Everyone,
Looking for some quick advice. I'm in an investing competition and here are the rules.
-Start with 100k -Must own 5 different stocks at a time -No transaction costs -Must sell/buy one stock a week -Goes on for 10 weeks.
I need to maximize my return. Should I just buy some on-the-rise stocks and ride em multiple weeks, and sell when they start to drop? This doesn't last long obviously, so no reason to try to grab something trending down.
Any stocks in particular you think of as good for these first few weeks? Small consistent safe bets are what I'm looking for. <comment><USER2> If you can create multiple accounts for this competition I'd do that and run different strategies through all of them</comment>


Thousands of Web Users Delete Profiles From RapLeaf - <AUTHOR> http://online.wsj.com/article/SB10001424052702304248704575574653801361746.html

<comment><USER2> All the information they supposedly gathered about me was wrong. They think I'm a decade older than I am, that I live in a city I've never lived in and it lists my interests as electronics, charity, and current events, which is laughably general.

<comment><USER3> Similar for me. I'm male, and have an interest in photos and news. Probably from flickr + picasa, and here, as I certainly don't sign up on newspaper / magazine sites - that's what BugMeNot is for.

Help! Help! I'm being deanonymized!

Meh. They can keep it. And if it would mean fewer penis enlargement emails, they could have _more_.

</comment></comment><comment><AUTHOR> <https://www.rapleaf.com/opt_out>

<comment><USER4> According to Rapleaf's blog, this site has a bunch of opt out cookies you can use: <http://www.networkadvertising.org/managing/opt_out.asp>

Nice find. Opting out by email doesn't seem that useful though. I probably have 20+ emails associated with my person, and figuring them all out will be a lot of work.

There needs to be some kind of statutory privacy protection that targets both keepers of such information and consumers of the information.

<comment><USER3> To be bypassed at all times by anyone interested in making a buck on others' data, with a bit less in the way of scruples.

You _cannot_ prevent it all, and not all of it is even illegitimate - how can you tell the difference, if not on a case-by-case, human-decided basis? In which case, the cost would be astronomical; I'm not paying it. It'd be wrong sometimes anyway. At best, you can make it difficult for legitimate uses to exist, and do only a little to slow the illegitimate. And push them underground, making finding and _stopping_ them harder than it already is.

Heck, Facebook can be seen as a massive deanonymizer, and they exposed _way_ more (and more accurate) info about me publicly through their API. Their _ads_ were horrendously inaccurate, but prior to deleting my account they were probably the most accurate measure of "me" online by an order of magnitude. And any attempt to restrict public access to the data - useful for a number of services / applications - would make lots of legitimate uses impossible.

</comment></comment></comment><comment> X-Istence The data they have on me is all publicly available to begin with (LinkedIn, Portfolio website). They have absolutely nothing that may be of any use to advertisers. I am listed in just two categories:

Internet Internet > Online Streamers > Photo Sharing Consumers

No shit sherlock. I've got a Flickr account, and I am on the Internet. Apparently I am not a big influencer ... how little do they know that I have a multitude of accounts on various forums and social networking platforms with thousands of people that read what I write.

At least for me their system is a complete joke.

<comment><USER5> The info is publicly available, but they are linking it together in a machine readable way. It wouldn't take much to add one of your 'multitude of accounts' and then the information would become more specific (interest wise) and also directly traceable to you.

<comment> X-Istence They would have to link it using data that is NOT publicly available, and that is what seems to be their issue is that they can only use publicly available to machine link stuff together, data I've put out there for everyone to see under specific names/email addresses on purpose in a controlled manner.

While yes I agree the possibility is there, it is really remote.

</comment></comment></comment><comment><USER6> When will people learn that opting people in by default while pretending to be Mother Theresa out to save the world is going to backfire? If you want to offer a personalized experience that requires privacy-sensitive data gathering, give users a good reason to opt in and give them full control. Otherwise, how are you any different than spammers? If people don't opt in, then your "personalization" sucks and you need to rethink your strategy.</comment>


Ask HN: Quantum physics observer effect = lazy evaluation? - <AUTHOR>

therefore we are a computer simulation. I'm drunk please be gentle <comment><USER2> (I'll repot an old comment that I made in a previous submission of similar article.)

Quite the opposite, if reality were a simulation this is equivalent to more process power instead of less process power.

When you use Classic Mechanics, you only need to "simulate" one trajectory.

With Quantum Mechanics the system may have a few choices, and you must keep the details of all the possibilities. The easy case is a qbit that only has two choices. But if you have a few qbits nearby, they may interact and now you must "simulate" the 2^n possibilities. This is why if we can ever build a quantum computer, it would be exponentially more powerful than a classic computer.</comment>


Scan your Slack history and build an FAQ bot automatically - <AUTHOR> https://www.onebar.io/use-cases/for-helpdesk <comment><AUTHOR> Hey, HN!

We've spent the last five months playing with BERT, Universal Sentence Encoder, FAISS, and other cool tools, and look at what we've built!

You can point this thing at any of your Slack channels (preferably one with many Q&As), and it will automatically build an FAQ bot out of it^

The bot will then stay in the channel and respond to trivial questions using previous conversations - kind of what helpdesk teams do half of the times but manually.

^ - automatically, but with some human curation

^^ - yes, it screams privacy concerns, but we only scan what you tell us to, and helpdesk channels usually only have boring stuff about laptops, licenses, and VPNs not working. Please don't add our bot to your top-secret channels.

So, what do you think?</comment>


Salary and perks at 37 signals(basecamp) - <AUTHOR> https://m.signalvnoise.com/employee-benefits-at-basecamp-d2d46fd06c58#.kbez9z913 <comment><USER2> Dupe of [https://news.ycombinator.com/item?id=10873063](https://news.ycombinator.com/item?id=10873063)

plus 9 other dupes

</comment><comment><USER3> What would a top 5% salary be?</comment>