In the Defense of Spaghetti Code (2013) - <AUTHOR> http://250bpm.com/blog:36 <comment><USER2> I understand the author origin point: To an extent, you cannot simplify an already complex domain problem with code. However, this has nothing to do with Spaghetti code. You could have one 1500 lines function that is not spaghetti code. It's hard to imagine, but it's possible. Similarly you can definitely have a bunch of functions, classes etc. that are spaghetti code, even if they are 3 lines each. Spaghetti is about the order in which you make your calls, the convoluteness of your loop etc.

I think the only point of the article is "Don't try to retro engineer the logic behind a complex domain that you do not master".

<comment><USER3> Yes - spaghetti code adds a dimension of complexity that is distinct from mere size, and in fact spaghetti code might be smaller than the same algorithm written as structured code (by the way, large blocks of structured code can be imagined by thinking of taking good code and inlining all the functions, with variable renaming to avoid clashes.)

It is fortunate that it is possible to show, via Turing completeness, that spaghetti code cannot compute anything that structured code cannot, for if not, we would still have programmers insisting (as some did, in response to 'Goto Considered Harmful') that spaghetti code is sometimes necessary.

> I think the only point of the article is "Don't try to retro engineer the > logic behind a complex domain that you do not master".

AKA Chesterton's Fence:

[https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)

<comment><USER4> I agree with the first of what you're saying but just wanted to add to others: Structured Code was a software engineer paradigm that didn't just mean "well organized" aka structured well; it was about specific constructs and conventions. Just as Functional Programming isn't just about having functions or being functional as in useful.

Also, I always think Turing Completeness is a red herring in conversations about Software Engineering. Turing Completeness is such a low bar, that it hardly factors into most conversations about the expression problem. It's most notable when the goal is to actively restrict completeness.

It's kinda like starting a conversation about birds and first establishing they have mass.

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

<comment><USER3> Structured programming, in the specific sense that we are both talking about, was such an influential paradigm that most programmers today, other than those using assembler, haven't seen anything else. Maybe that is why the author of this article seems to think 'spaghetti code' simply means large functions.

And I'm just pointing out that in this particular case, Turing completeness was very useful in decisively stopping what would have otherwise been an unending and inconclusive argument, and, regardless of whether or not it can justifiably be called a low bar, it was good enough in this case. Furthermore, It does the same in many other cases: for example, in the question of whether there are ISAs that are more computationally powerful than others. It seems to be, or at least have been, very useful in computer science even if it does not have much relevance to everyday coding, and it may not seem much of a big deal because the questions that it has solved are no longer (or never became) problems.

<comment><USER4> Huh. I made the comment about Turing Completeness being "low-bar" from the perspective of Turing tarpits [0] or NAND universality (which needs memory/flip-flops). It seems to be easy enough that languages like Brainfuck can be Turing complete with a handful of elements. So much so that C++ templates or extended regexs seem to _accidentally_ be found to be Turning Complete.

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

> In any Turing complete language, it is possible to write any computer > program, so in a very rigorous sense nearly all programming languages are > equally capable.

You seem to have more history on the matter than I do, so let me ask a question instead trying to defend that idea. Why did anyone think Structured Programming wouldn't be? They must have had reasons to suspect it. I also don't know much of the history of Structured Programming apart from "Goto Considered Harmful", so pointers would be great.

<comment><USER3> I don't think those programmers, who claimed that structured code was insufficient, had thought about it in those terms. They were probably proud of their skills and the programs they wrote, and tried to defend it as the right way to do things, as it seemed obvious to them, from their experience, that it was.

</comment></comment></comment></comment></comment></comment><comment><USER5> The article's argument is a _reductio ad absurdum_ that flows from the outcome of the purportedly reasonable refactoring of this:

      int new_sequence_number (int old_sqn, int foosoft)
      {
          if (foosoft == 2) // version 5.34.2 of the protocol
              return old_sqn + 3;
          else if (foosoft)
              return old_sqn + 2;
          else
              return old_sqn + 1;
      }

into this:

      int new_sequence_number (int old_sqn, int step)
      {
          return old_sqn + 1 + step;
      }

The problem is that this _isn't_ reasonable. Though the function signature looks the same, _foosoft_ is an enumeration of some kind but _step_ is actually an integer— This sort of change requires an audit of all call sites, as the meaning of one of the arguments has changed.

One big red flag here is that the new function body isn't what you'd expect from its signature. Why is the sequence number incremented by _step_ +1 instead of _step_? The only reason I can think of is that they want to maintain compatibility with an old callsite, but that doesn't make sense with the category change of the argument.

Ideally, the function signature itself should change so that the compiler will point out all of the obsolete usages to you. If you can't do that with the type system, change the function name.

<comment><USER6> What you're attacking is IMHO just a part of a side-note of the actual argument; sure, that's a bad way to refactor the function. But even with an appropriate refactor, the codebase as a (fragmented) whole remains less readable and maintainable than a long spaghetti function _potentially_ is.

Because the problems now cut across responsibilities of the components built on certain assumptions made for the sake of removing the spaghetti. Because now you need to account for "global" parameters (protocol version) in lots of disparate "local" scopes - individual functions who are quickly losing their degree of encapsulation.

We're discussing a hypothetical code-base, so focusing on the details isn't probably going to be too helpful. In any case however, I in no way see how the argument "flows from the outcome" of the refactor you're focusing on.

<comment><USER5> By using a hypothetical to support his argument, the author is implicitly asserting that his hypothetical is representative of the real-world situations we're trying to discuss. He had the freedom to pick the strongest example possible, or several varied examples, and chose to use only this one.

Specifically, he's using the failed outcome of this hypothetical refactoring to argue that _new_sequence_number_ should never have been broken out into a separate function in the first place because it separated the _foosoft==3_ case from the conditional, which made the bad refactor more likely to happen.

Certainly, in this hypothetical 1500-line function, it's possible that they would have appeared close to each other and it's possible they wouldn't have. In this particular case, it's entirely possible that the refactor was made _easier_ to execute successfully because the programmer can leverage the compiler to find all the locations that need to be updated.

In the end, he's demonstrated a flawed hypothetical procedure and asserted that it's worse than an imagined alternative. As usual, the argument being unsound doesn't mean the conclusion is incorrect, only that it hasn't been demonstrated here.

</comment></comment></comment><comment><USER7> Lots of small functions and special classes being called left and right can be much more difficult to follow than just the whole logic written out consecutive.

<comment><USER8> It's all about balance really and this is part of the problem.

1500 lines of code for a function/method would strongly _suggest_ a problem. In the same way as a 200 function/methods would make it hard to follow.

<comment><USER9> If breaking up a procedure results in the creation of a bunch of smaller procedures that are only called once then I think I'd prefer to leave it as it was with well demarcated and commented sub-sections.

It saves you the job of inventing descriptive procedure names as well as jumping between procedures.

I seem to recall also that in Code Complete, Steve McConnell claimed that there was an inverse relation between the length of a procedure and the number of errors per line of code.

<comment><USER10> How is an inline function different from a demarcated and commented subsection? It seems to me that the semantic and enforced correctness benefits of functions would make using them in this way a no brainer.

<comment><USER11> This exactly when you break up a logically flat function into subfunctions, the names of those functions are simply replacing comments.

</comment></comment></comment></comment></comment><comment><USER12> > PS. If you happen to be a developer of a static analysis tool: Consider > leaving long functions alone, rather then reporting them as suspicious. > There are circumstances where long functions are perfectly legal and > desirable.

Sure, _there are_ circumstances. They're just extremely rare and their occurrence is dependent on the team as well. So generally, I'd say function length a pretty good proxy for complexity--as long as there are overrides.

<comment><USER13> I disagree with this. I think something should be a seperate function only if it is (or likely will be) called from several callsites.

If you try to not always think about contrived cases while writing code, then this rule can sometimes lead to quite long functions simply from executing steps in sequence ("script").

One can split what is really a long function into several small ones for readability, but if one does so I think one should declare that function within the calling function (in languages that support this), and whether one does that or not is really about as insignificant as tab vs spaces or where one likes to have curly braces.

My point is, if a function only has one callsite, and is not likely to get more (incl. test code), then whether to inline that function or write it seperately is a style/formatting issue, not a maintainability issue.

<comment><USER14> > I disagree with this. I think something should be a seperate function only > if it is (or likely will be) called from several callsites.

I disagree. I split out anything that I can describe/test separately. If I need to take a list and

1\. Filter it based on custom logic 2\. Sort it based on custom logic

Then I will generally break the filter and sort out into their own functions even if they're not used anywhere else. Each function can have it's own description and tests.

<comment><USER13> I understand that many prefer this. My point wasn't really so much mine or your preference -- my point was that it is a question of stylistic preference, not about spaghetti vs not.

As you simply describe your own stylistic preference I am not sure if you agree with me about that or not?

If you actually write a seperate test for the function then you have two callsites and of course it must be a seperate function.

</comment></comment></comment></comment><comment><USER15> Yes. Over-engineering is a thing. Also, there are problems that cannot be simplified (e.g. Implementing a Calendar class [http://yourcalendricalfallacyis.com/](http://yourcalendricalfallacyis.com/) )

I agree with other comments that Spaghetti Code is not the right term for this. But, the original point is valid.

The other part of the point is also true. To hide implementation inside functions makes sense if the function is part of the real world domain. To do a cut/paste to extract lines of codes of a big function to make it look nicer may increased complexity as now jumping around the code is needed to read it.

</comment><comment><USER16> I don't dare to call it spaghetti code because (among the other things) it's split in a lot of functions, but to give an example that's probably equally difficult to everybody, check this Erlang module that parses ASN1 [1]

A few hints about the language for the non-functional crowd, then my point

1) Functions can have multiple definitions and are picked top to bottom. The one that runs is the first one matching the arguments in the call.

2) Variables are Capitalized (and can't be assigned again, big surprise.)

3) Atoms (:symbols in other languages) are lower_cased.

4) The arrow (->), the comma (,) and the dot (.) do (more or less) what Java/C do with their { ; } characters (sorry, I have to keep it short)

You can start from the bottom and go through the get_token, get_line, parse_ComponentTypeLists etc, find where they are called and see how they neatly (IMHO) replace the switch statements in other languages.

Is it easier to understand? Hard to tell: if the problem is difficult the code won't be easy. Is it less tangled? I think it is. My point: some languages are messiers than others.

[1] [https://github.com/erlang/otp/blob/master/lib/asn1/src/asn1c...](https://github.com/erlang/otp/blob/master/lib/asn1/src/asn1ct_parser2.erl)

<comment><USER17> To add to this (for those unfamiliar with Erlang/OTP): Erlang not only has general pattern matching, but also specific support for pattern matching on binary content (down to bitfields). It's better than C and C++ in that regard in more than one way.

</comment></comment><comment><USER18> ...spaghetti code isn't a monolithic function, it's a constellation of tightly-coupled but separate entities, woven together like a big knot. I.e., exactly the thing the author advises against.

Terminology aside, he does make a good point: if the domain can't truly be broken down into clean parts, encapsulation can do more harm than good as you have to weave all these contingencies through every layer.

</comment><comment><USER6> Key takeaway is this:

>The point I am trying to make in this article is that sometimes it's the problem domain itself that's complex and convoluted. In short, it's a spaghetti domain.

I definitely have encountered spaghetti domains and have bashed my head against them, trying to find nice, clean and elegant abstractions that describe the problem succinctly and clearly.

Sometimes there's just more exceptions than rules, and spaghetti code is not a bad outcome. As with all guidelines, do not follow blindly where a less "conventional" solution makes sense?

<comment><USER9> I agree, spaghetti domain seems to be a useful concept. It allows you to just get on with coding a solution.

</comment></comment><comment><USER19> If using something that ought to be an enum as an integer to save a few lines of code isn't spaghettification then I don't know what is. Rather predictably it doesn't generalise.

It's called spaghetti because it's hard to see what information flows where, not just because some information flows are long (at least, my mental image for spaghetti-code has always been _cooked_ spaghetti).

</comment><comment><USER20> > Luckily though, 45 years after Dijkstra's paper, goto is not used > extensively any more.

goto might not literally be used any more, but I see "break" used a lot, and for long functions that have variables defined outside of the scope of the "break," it behaves similarly.

<comment><USER21> It would be interesting to go back through old code containing GOTO's, and see if the main use was similar to "break."

</comment></comment><comment><USER22> I don't think the article proves what it claims to prove. Original modification was reasonable and no abdomination. The second so called beautification, the one that expects the caller to guess step size, was definitely not improvement.

More importantly, author seems to just give up around

> After few such iterations the code that was originally nice and manageable > becomes a mess of short functions plagued by lots of behavior-modifying > arguments, the clean boundaries between components and layers are slowly > dissolved and nobody is sure anymore what effect any particular change may > have.

Yes, that is how spaghetti code happen.

But, if all those conditions were embedded in a single 1500 lines long function, the situation would be no better. You would have interconnected monstrous system of conditions.

</comment><comment><USER23> There is a fine line between DRY and human-Huffman-encoder.

Just knowing that the line exists makes a big difference!

<comment><USER24> I'm stealing that analogy, it's perfect. Huffman encoded codebases give me rage tantrums when debugging.

</comment></comment><comment><USER25> In this particular situation, I would be much quicker to go for copy/pasted code than spaghetti code.

I worked at a place where we had to interact with financial exchanges, which nominally talk standard protocols but actually all have their own quirks in their implementations of the protocols, which we had to account for on our own end. They ended up going with the copy/paste approach, and, while I was initially horrified, I came to realize that they're right.

The admonishment against copy/paste is meant to deal with the risk of accidentally forgetting to update one of the copies when there's a new change that needs to be pushed across all of them. It turns out that, for the problem domain we were working in, which sounds quite similar to the one TFI describes, _that never happens_. Even when the standards body releases a new version of the protocol, each vendor upgrades on their own schedule, and the slowest-moving vendor might stick on the old version for 5 or even 10 years, and when they finally do get around to it, their implementation of that feature will have its own quirks, so just setting a flag saying, "Vendor X is now on version Y" wasn't going to work, anyway. So then you (hypothetically) create a set of flags saying, "Vendor X is using version Y, but with these behaviors that differ from everyone else's version of Y", add a bunch of new if-statements, and the actual logic that might execute at run-time gets even more obfuscated behind a tangle of counterfactual configurations that won't happen in real life but still exist in the code and are supported in the application.

So, to sum up: nominally the same protocol, but everyone does it differently, and upgrades on their own schedule. It really is a horrendous tangle. Dealing with that mess by mirroring it in your code with an equally tangled pile of flags and conditionals is also going to be a mess, no matter how you choose to organize the code.

Don't do that. Alexander the Great was right: Sometimes the best way to deal with these sorts of things is by cutting them into pieces. Then, when you're dealing with one implementation's quirks, you only have to be thinking about that one set of quirks, and not the combinatorial explosion of possible interactions that you get when you try to mix them all together.

</comment><comment><USER26> In this example the problem is the spaghetti code _in the specification_ , which you have no control over.

This then inevitably causes the resulting spaghetti code.

<comment> UK-Al05 You can however nicely isolate the code which has behaviour changes for each vendor.

<comment><USER27> Typically resulting in ravioli code instead. Or an explicit state machine, even worse to follow.

[https://en.wikipedia.org/wiki/Spaghetti_code#Ravioli_code](https://en.wikipedia.org/wiki/Spaghetti_code#Ravioli_code)

(Wanted to link C2 wiki but it's a goner.)

You cannot fix essential complexity with any kind of design. If there are options in design, your code will reflect them at some layer. You might want to suggest, say, Component or entity-based or other design, or mixins, or other object level patches for conditionals.

Spaghetti if otherwise well structured is quite understandable. The more advanced versions? Not nearly. Spaghetti is explicit at least.

<comment><USER5> > You cannot fix essential complexity with any kind of design. If there are > options in design, your code will reflect them at some layer.

That's certainly true; my favorite method at the moment for this sort of thing is to make it data-driven: have a structure that contains all of the parameters that change based on vendor (including enums/flags for optional behaviors) and a single process implementation that refers to it when needed.

<comment><USER27> You end up with a big if-then block. Essentially spaghetti but localized.

A joke I sometimes make is that spaghetti is best of a plate or in a box from which it cannot escape. Otherwise it would spill.

Ravioli does not spill but the relationships become implicit.

<comment><USER5> Localized is good. It means that the next time there's a new thing, there's only one place you need to change to specify its unique set of properties. Often, this can even be removed from the code entirely into a configuration file, so that a recompilation isn't necessary for every new situation.

</comment></comment></comment></comment></comment></comment><comment><USER28> If the requirements are complex, then you list the requirements, what you're doing with each one, how they connect, and the code reflects that. Breaking it into functions and modules for that often does enough. At the least, the design documentation will facilitate understanding even if the code itself is harder to understand.

Spaghetti code is almost always just bad design and coding.

</comment><comment><USER29> A refactored code and the spaghetti version are two sides of the same code. Just like any complex object requires multiple viewpoints to comprehend, asserting one perspective is superior to the other is missing the picture. It is a pity that modern practice is always one or the other. It is possible to have both. Literate programming is one example.

</comment><comment><USER30> I cut my coding teeth in assembly, followed by FORTRAN IV and a smattering of Apple, Commodire, and TI BASIC (with their gosubs and peek/pokes). I've worked with real spaghetti code.

What most people call spaghetti code these days is just code. Useful programs are complex and have complex code. Modern software might be difficult to follow, espcially if you're at an amateur or junior level (which is probably 80% of the people out there reading code, cf. Dunning-Kreuger). It's not generally spaghetti.

</comment><comment><USER31> (2013)</comment>


King Tut's dagger blade made from meteorite, study confirms - <AUTHOR> http://www.cbc.ca/beta/news/technology/king-tut-dagger-1.3610539 <comment><USER2> The bronze age in that part of the world was around 3300 to 1200BC. Tutankhamen ruled from 1332 to 1323. From that alone we might suppose why a bit of proper iron was more valuable than gold. (the Hittite secret of iron wasn't for another 275 years despite Mika Waltari's poignant novel "The Egyptian" which had the Hittites flashing their iron about the court of King Tut)

<comment><USER3> Interesting I didnt know that at all. Your "proper iron was more valuable" comment reminds me of about a little different period from a documentary that I watched that talked about the time around 700BC where Umayyad empires used silver coins while gold and copper coins were used in Egypt/Syria.

<comment><USER4> Not to mention that aluminum used to be more valuable than silver.

[https://en.wikipedia.org/wiki/Washington_monument#Aluminum_a...](https://en.wikipedia.org/wiki/Washington_monument#Aluminum_apex)

<comment><USER3> Correct, I believe this was also what I read about how it being more valuable allowed these ancient civilizations who had access to it, to have some more monetary value to their coins and also showed their political influence (Ex: a picture of their leader ) when they traded with other civilizations overseas

<comment><USER5> >I read about how it being more valuable allowed these ancient civilizations who had access to it, to have some more monetary value to their coins and also showed their political influence (Ex: a picture of their leader )

Probably 1 of 3 reasons Gold was valuable at all to the ancients:

1\. Gold is the most malleable of all the metals, making it easy to coin in extreme detail.

2\. Antimicrobial properties (probably known to the ancients).

3\. Oh look, its shiny!!! We are no less vain now, than then. Or perhaps no less vain then, than now.

Edit: Sorry I think you were referencing aluminum.

<comment><USER6> Gold was also the heaviest known element until the middle of the 19th century, which means that all impurities swim at the top and so it is easy to purify simply by melting it. Plus you can assay it by a touchstone. So there are a lot properties that make Gold the best metal for coins.

<comment><USER7> This only applies to impurities that don't dissolve in, or alloy with gold. For example, silver and copper cannot be removed from gold simply by melting because they form solution alloys that don't segregate in the molten state. Some solution alloys of gold include crown gold (silver, copper, gold) and white gold (palladium, nickel, gold).

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The Egyptians called iron the 'metal of heaven', 'ba-en-pet' because it came from meteorites. This was back in the bronze age, they could work it but not make it themselves yet. Meteorite iron is known to be magnetic as well so it's possible this would have seemed 'magical' as well.

</comment><comment><USER9> I;m surprised nobody has mentioned the many other cultures that made tools out of space iron, both before and long after the Egyptians.

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

"For centuries, Inuit living near the meteorites used them as a source of metal for tools and harpoons. The Inuit would work the metal using cold forging—that is, by stamping and hammering it."

</comment><comment><USER10> As others have mentioned, different metals and the propensity to work them require differing amounts of knowledge. They also require _vastly_ different amounts of _fuel_.

Egypt was fuel-starved. Its only arable region is along the banks of the Nile river, a band at best a few kilometers wide, which _to this day_ remains the population center of the country. Wood came either from up-river (rarely), or from other points in the Mediterranean. I'm weak on the specifics, but the ancient references to the Pines of Lebanon bear on this.

Meteoric iron is valuable because it is _molecularly pure iron_. It's essentially supernova ash -- what's left after the final stages of stellar fusion result in least-nuclear-potential atoms, iron and nickel. It's molecularly pure because it hasn't _rusted_ \-- in space, no one can hear you rust, either.

Iron on Earth is rusted in large part due to the early stages of biological evolution in which _the great oxygenation event_ occurred, and with it _the great rusting_ \-- oxidation of what was, at the time, pure molecular iron lying on Earth's surface, with the now newly-available oxygen. Semlting is a de-oxidation process.

Many of the great iron ore fields are also the result of _biological_ activity -- early-stage microbial life using iron (I am not sure of how specifically) in its own metabolic processes, and depositing large stratified bands of iron as a result. _These ores are 1-3 billion years old._ As with other resources, they're among those humans have been tearing through, literally, at an amazing clip over the past 200 years.

Iron smelting prior to the age of _coal_ was performed using _charcoal_. Charcoal kilns -- you can find pictures online -- are large beehive-shaped stone structures which were stacked full of wood and lit afire. The wood was _pyrolised_ but not _combusted_ , pushing out the impurities. This is close in chemical properties to coal which is, in essence, wood subject to somewhat longer pyrolisation processes, as well as geological formation.

And the modern switch from charcoal to coal (originally sea-coal, opportunistically harvested chunks broken from open seams along the English seashore) occurred as what had been a heavily-forested Britain was exhausting its own renewable wood resource and turned instead to coal. An activity which already by the late 1700s was recognised as unsustainable (John Williams, _A Natural History of the Mineral Kingdom_ , 1789).

Discussed at greater length in William Stanley Jevons' _The Coal Question_ :

[https://archive.org/stream/coalquestioninqu00jevo#page/14/mo...](https://archive.org/stream/coalquestioninqu00jevo#page/14/mode/2up)

</comment><comment><USER11> Is it quite normal to call him King "Tut"?

<comment><USER12> I have always thought -- without any evidence -- of it as an American Thing. Like Farenheit temperatures.

As a kid I learned on TV about a pharaoh named Tutenkhamon, and at some point became aware of some Egyptian named "King Tut", who must surely be the same dude.

Though come to think of it, now that we have this interweb thingy, it's worth checking...

<comment><USER13> > The discoveries in the tomb were prominent news in the 1920s. Tutankhamen > came to be called by a modern neologism, "King Tut". Ancient Egyptian > references became common in popular culture, including Tin Pan Alley songs; > the most popular of the latter was "Old King Tut" by Harry Von Tilzer from > 1923, which was recorded by such prominent artists of the time as Jones & > Hare and Sophie Tucker.

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

<comment><USER14> The shortening certainly works better in newspaper headlines and song lyrics!

</comment></comment></comment></comment><comment><USER15> People view old Egyptian culture as one homogeneous whole when in fact there were major tech changes over the millennia. Some elements like the formal writing did stay somewhat constant.

First, the dyration of dynasty was one and a half times longer than our time back to Jesus. That is a long time! Maybe the Catholic Church starts to approach with some factors staying constant during 2000 years and others changing.

Second there were major tech upgrades at times icluding the adoption of the wheel, the horse and iron weapons. Enemy armies discovered these first, beat up Egyptians, who then eventually learned these new techs.

<comment><USER16> >People view old Egyptian culture as one homogeneous whole when in fact there were major tech changes over the millennia.

I think viewing them as homogenous has basis in the fact that their religion, belief systems, social structures remained virtually unchanged for thousands of years.

Ofcourse they built better boats, better tools, better tombs, better textiles, better mummifications techniques; but underlying philosophy and religion was virtually unchanged from old dynasty to Cleopatra.

</comment></comment><comment><USER17> How did the ancient Egyptians know it came from the sky?

<comment><USER18> IANAA.

They probably see it. Let's make up a story without any proof that it's real:

In some place in the countryside, they see a light moving in the sky and a not very far explosion. (The ones that see a nearby explosion are dead.) Imagine something like the meteorite at Russia a few years ago. (From the videos it looks like a nice show if it doesn't land on your head.)

The local governor/priest/whatever heard about it and send a crew to the site, let's say 5-10 persons. They found some molten glass and a strange metal stone, that is like bronze but has a weird color.

They share the story for generations, if you are lucky someone they wrote an inform for the pharaoh. Everyone think they are nuts, but a they have this weird stone.

Wait a few centuries, and repeat this a few times, and now you have a collection of weird stones and/or the weapons/tools made with them, and they share a similar story. So the story is not long so weird.

Anyway, the knife made with the stone is better than the usual knives, and it has a nice story, so someone send it to the pharaoh.

<comment><USER19> Or it's special because it literally came from the heavens (to them) so it must be to make the weapons for the kings, possibly even sent by the gods for just that purpose, especially if it happened to blow up some people the people in power didn't like in the process of smashing into the ground.

All of that is pure speculation on my part, but it'd be really interesting to find out how far off my guess is.

</comment></comment></comment><comment><USER20> Check out the documentary Secrets of the Viking Sword. Goes into great depth concerning the materials and methods used in creating the Ulfberht blades. Don't remember meteorites being mentioned though. Maybe they simply didn't mention it in this documentary.

<comment><USER21> apparently the Vikings got the steel for their swords from as far away as Central Asia and India. and that steel was critical to the superior performance of those blades.

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

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

<comment><USER22> The famed Ulfberht sword is believed to have used steel forged in northern Iran, and transported through the Volga trade route (that followed the Volga river into the Caspian sea):

[http://www.pbs.org/wgbh/nova/ancient/volga- trade.html](http://www.pbs.org/wgbh/nova/ancient/volga-trade.html)

</comment></comment></comment><comment><USER23> Aliens built the pyramids confirmed. Tutankhamon was a reptilian.</comment>


Negotiating Your Startup Job Offer - <AUTHOR> http://rob.by/2013/negotiating-your-startup-job-offer

<comment><USER2> I have definitely come to the view recently that a seed-stage startup is not a good thing for an experienced engineer to join unless it is as a founder. The odds of it being worth the salary cut are just too low.

</comment><comment><USER3> I think it's one of the best posts I've ever seen on stock options. Too many people think too much of their stock options, while in reality in most cases they are worth close to nothing. This is something everyone has to consider when their employer offers them to trade salary for equity.

I made this mistake once, I wish I had read this post then...

</comment><comment><USER4> Cool post - one correction:

 _Your stock was restricted, not common._

should be:

 _Your stock was common, not preferred._

You typically don't get restricted stock through exercise of a stock option, you get common. And investors get their liquidation preference through preferred stock, not common.

<comment><AUTHOR> Thanks for catching this; I updated accordingly.

</comment></comment><comment><USER5> I think this was the most important point regarding equity: "The only thing that matters in terms of your equity when you join a startup is what percent of the company they are giving you. If management tells you the number of shares and not the total shares outstanding so you can't compute the percent you own – don't join the company! They are dishonest and are tricking you and will trick you again many times."

I have twice worked for companies that presented my options this way. Although one of them worked out very well for me, and the other is likely to as well, it's still sketchy. I wish this post had been around back then :) That being said, I will be referring back to it in the future!

</comment><comment><USER6> I have no idea why a person would want to be an _employee_ of a startup at an early stage. Seems like you get all of the downside with none/little of the upside.

Can anyone that sees things differently provide some reasons?

<comment><AUTHOR> My goal at my first startup was to optimize for learning and it served me very well for that. The perks I got:

\- Met investors and learned about the entire investing process

\- Got immersed in metrics/data-driven product development

\- Had a ton of autonomy even as a non-senior developer.

\- Made a name for myself in the local ecosystem.

\- Got to spend my time developing a product I loved and believed in.

<comment><USER6> These are all good reasons, but they strike me as being much more valuable to a person that is new in the industry, rather than one with several years of experience.

I can certainly see the appeal for someone looking for experience, but I still don't see it for a seasoned professional.

To me it seems as the only valid dichotomy is between being a founder yourself or working as an employee in a more established (but still perhaps small) business.

</comment></comment></comment><comment><USER7> A great read, all in all negotiation 101 techniques still work:

\- Put your fence post out first by setting a number that you could get elsewhere \- Mention that you love the company and are willing to take a partial cut on a higher alternative but cant do more than that \- Assume the stock wont be worth much at all, explain although you strongly believe in the company most start-ups fail \- Confidence is important

<comment><USER8> This is great, thanks for this!

</comment></comment><comment><USER9> Question regarding stock options: I have some but I'm not sure if the company will ever sell for enough to make it lucrative for me, however that assumption and my knowledge of the company are based on what I've casually been told, what I've observed, does being offered stock options (or purchasing stock) grant me access to financial information or some sort of "insider" information that would allow me to make a better informed decision?

<comment><AUTHOR> Not if the company is privately held.

Your options agreement should tell you how many shares you have rights on and what your strike price is. The company, if run honestly and transparently, will tell you how many shares are outstanding and what the current valuation is. From there you can do the math on potential outcomes. If they won't give you formal disclosure of that information, assume the worst.

<comment><USER10> I'm pretty sure this is wrong. I think in California and Delaware (most startups) stockholders are entitled to see the financials of the company.

I doubt most companies would deny this right if you sent a notarized/certified letter with notice. And in the worst case a judge would most likely side with the stockholder.

IANAL

<comment><AUTHOR> The problem is that he's not a stockholder. He doesn't become one until/unless he exercises the options.

<comment><USER10> So he buys one share?

</comment></comment></comment></comment></comment><comment><USER11> At what point did it become OK for investors to eat such a gaping chunk of equity by simply contributing money, when founders/engineers/technical talent contribute not just money, but time and effort as well?

Is it simply because they are the ones holding the cards? If so, fuck that, and fuck investors.

<comment><USER12> > _At what point did it become OK_

When everyone agreed to it, I suppose.

> _If so, fuck that, and fuck investors._

This seems rather naive. No one takes investors for the fun of it. Investment describes a mutually beneficial relationship that occurs when an enterprise needs funding. Investors shoulder the financial risk and burden and thus demand compensation in the form of (probably worthless) equity.

<comment><USER13> You are right, the burden is on those taking investment to make sure it is good for them. On the other hand, there may be negative externalities to a mutually beneficial deal between an investor and a founder, for an early employee.

</comment></comment></comment><comment><USER14> How do I know how much a company is worth and how many shares it has? Is there some public source where I can look up for this information?

Startup job offers usually just give you how much stock they're offering you but without any information to see how much it's really worth

<comment><USER15> This is not a sure bet, but just ask about their latest funding round and how much they got and how much of a percentage they gave to the investors. For example, Company X just closed a 1 million dollar Series A and gave up 50% equity. That means the company is valuated @ $2 million.

</comment></comment><comment><USER16> Good read as I'm currently entertaining a 1% stake in a seeded company for 1/2 my market rate, with a valuation of $5 mil.

<comment><USER17> Citing both the article and my personal experience, it would take more than that to make that deal worth taking.</comment></comment>


18 Million MORE voter records exposed - <AUTHOR> http://www.csoonline.com/article/3018912/security/18-million-targeted-voter-records-exposed-by-database-error.html <comment><AUTHOR> This is in additional to the 191 Million exposed last week

[http://reuters.com/article/us-usa-voters-breach- idUKKBN0UB1E...](http://reuters.com/article/us-usa-voters-breach- idUKKBN0UB1E020151229)

apparently this is breaking all kinds of laws but no-one is being arrested</comment>


Usql: v0.7.0 released - <AUTHOR> https://github.com/xo/usql/releases/tag/v0.7.0 <comment><AUTHOR> Just released the latest version of usql, which fixes issues with syntax highlighting, adds initial support for Cassandra databases via CQL, among other changes.

If you've not seen usql before, it's a universal command-line client for SQL databases (and now also Cassandra), modeled on psql. usql makes it easy to work from the command-line, in a simple and consistent way across any database and on any platform (Windows, macOS, Linux). usql is written in Go, and provides things like syntax highlighting and compatibility with databases other than PostgreSQL (see below for the list of the supported databases).

Progress is moving at a decent clip towards a v1.0, which I expect to include 100% native Go support for Oracle databases, tab-completion, full compatibility with psql's \pset (and other output formatting) commands.

usql supports the following databases:

        Microsoft SQL Server
        MySQL
        PostgreSQL
        SQLite3
        Oracle
        Apache Avatica
        Cassandra
        ClickHouse
        Couchbase
        Cznic QL
        Firebird SQL
        Microsoft ADODB (Windows only)
        ODBC
        Presto
        SAP HANA
        VoltDB

Hope others in the community can make use of usql. Glad to answer any questions if anyone has any.

<comment><USER2> ODBC isn't a "database" per se, but a standard interface that can access any database with an ODBC driver.

...and although I'm not familiar with all of the others in that list, the ones that I do recognise have ODBC drivers.

<comment><AUTHOR> Yes and no. ODBC on Windows may (or may not) be provided by the Microsoft JET driver, which can be considered a database unto itself. Specifically, there is a separate ODBC driver for Go that usql supports, which is what this is reflective of. I actually edited the above after posting to remove a double entry for PostgreSQL and MySQL, as there are two different Go drivers for each of those databases (4 in total) that are well supported by the community.

</comment></comment></comment><comment><USER3> How would this compare to DBCLI?

[http://www.dbcli.com/](http://www.dbcli.com/)

pgcli

[https://www.pgcli.com/](https://www.pgcli.com/)

mycli

[https://www.mycli.net/](https://www.mycli.net/)

<comment><USER4> I'm the creator of dbcli. I can give you my perspective.

usql is a great tool if you're familiar with Postgres' psql client and wish you could use it for other databases like MySQL, Cassandra etc.

dbcli tools are designed to preserve the usage semantics of the existing tools but improve on them by providing auto-completion. For instance you can use `\d` in pgcli and `SHOW TABLES` in mycli. This was a conscious decision to make pgcli and mycli drop in replacements for of MySQL and psql. I was also working under the assumption that people rarely use multiple databases, you're either a postgres shop or a MySQL shop. If you have a mix of both, there is a good chance that not a single person is interacting with both of them on a daily basis. You have different teams using different databases. But my reasoning there could be flawed.

There is nothing stopping someone from adding an adapter to the usql tool to make it behave like MySQL (because they like the mysql client better) based on a command line argument, for instance.

<comment><USER5> As a data point, it seems to be reasonably common for people to use both SQLite + <some other database> (eg PG).

Probably because they have different use cases that don't overlap too much. eg SQLite is great for single file info storage and passing around. The others - being competing multi user servers - don't do that. :)

<comment><USER6> Up until very recently I used to regularly hop between sqlite3, Informix (don't hear much about that these days), MySQL (or compatible) and some key/value stores like Redis and memcache. Occasionally used to dip into MSSQL too but that wasn't often.

</comment></comment></comment></comment><comment><USER7> usql != U-SQL. One is a database client, the other a database language. This could become confusing.

<comment><USER8> Usql != Transoft U/SQL either

</comment></comment><comment><USER9> SQL is an initialism. Please capitalize it, as it should be. It stands for Standard Query Language.

<comment><USER10> A very large portion of developers I speak to pronounce it as 'seekwol'. Some of them also prefer tabs.

<comment><USER9> Acronyms should also be capitalized.

<comment><USER11> You mean like laser, radar and scuba?</comment></comment></comment></comment>


Show HN: Cliently – The fastest way to find a new freelance gig on Twitter - <AUTHOR> http://www.cliently.com <comment><AUTHOR> Hey guys,

We've built an app to help freelancers find more gigs easily and avoid competition that is overwhelming on Upwork, Odesk, etc.

We've just released our MVP and we are looking for some early testers of the idea in general and improvements we need to make. And if you break stuff -- it's even better!

How it works: we look for critical business events a company might have in several industries and filter the noise out. We started with twitter as it's the easiest one to test and will add other channel like angel list and crunchbase later on.

Thank you, Sasha.</comment>


Vivaldi Browser Enables Razer Chroma - <AUTHOR> https://vivaldi.com/blog/vivaldi-browser-enables-razer-chroma/ <comment><USER2> Thanks! That's super helpful. I might try it! Do you know if there's a way to disable or auto hide all the scroll bars, tab bars etc so it's basically like windowless? That and vertical bars are the main things keeping me on Firefox.

<comment><USER3> Good question! I didn't know but there is an experimental "Overlay Scrollbars" flag in vivaldi://flags that enables that and it's great (this is a perfect example of wondering if you can do something and then finding it's already a feature)

It looks like this: [https://imgur.com/a/CpUg78J](https://imgur.com/a/CpUg78J)

About the vertical bars, which ones are you referring to?

</comment></comment><comment><USER2> Finally, my browser can sync with my keyboard and mouse pad's colors! /s I do see this as a sign that Vivaldi is more willing to work on integrations. Is it worth considering over Firefox?

<comment><USER3> I am an AVID Vivaldi fan. Have never been happier with a browser. Quite a few times I wondered "can I do this?", turns out that the feature is already implemented or it's pretty easy to do it myself. It's a chromium browser so you know what you get in terms of rendering and extensions. The actual browser features are html/js/css and fully modifiable.

The only issue I ever had is that it used to be a bit slow on my Mac(borderline unusable) but it seems to have improved now.

Some of my favorite features:

\- Very detailed history \- great a and quick bookmarks \- embed pages in the side panel for quick access \- pretty cool note system that supports screenshots and markdown \- Themes (as you mentioned, this might not be essential but I don't like an eyesore) \- Page actions, this are small scripts/css that you can apply to any page and can come very handy.

I really can't think of a browser that would give me anything more. Maybe only the built-in VPN like Opera but I always use an extension.</comment></comment>


Best practices for JS and CSS organization - <AUTHOR> http://codefastdieyoung.com/2011/03/css-js-organization-best-practice/

<comment><USER2> I mildly disagree that coupling it to the controller makes the best sense. Maybe in MVC that isn't component structured, but even then, you'd probably want more granular control than that.

In Appleseed[1], I mapped CSS component views, and foundations. Foundations are layouts of components, and describe the whole page. Views describe a specific view of a component.

So, basically, if I have a component "example", with a view "list", then I can create a file in the default theme:

      themes/default/styles/components/example/list.css

It will only get loaded into the <head> if the list view of the example component is loaded. I do similar things for the client-side Javascript.

It is good that people are working towards figuring out these patterns, though. The sooner we can move away from the wild west of spaghetti css and javascript, the better.

[1] <http://wiki.appleseedproject.org/doku.php?id=developers>

<comment><USER3> I would say a big disadvantage of doing it this way is you're serving up different CSS/JS files for each page. The approach in the article lets you separate your CSS out into files based on general "concerns" that make sense to your developers, while being able to use an asset packaging tool like Jammit (or even mod_pagespeed) to package them into one large CSS file that can then be cached by the browser, ISP proxies, and your CDN sitewide.

<comment><USER2> _I would say a big disadvantage of doing it this way is you're serving up different CSS/JS files for each page._

You don't have to, though. You can put everything into a single global css file, and be done with it.

And I haven't implemented it, but I can immediately see easy ways to package it all up into single files that can be easily cached.

It's easier to consolidate the files programmatically after they've been logically separated, than to logically separate out of a monolithic location.

</comment></comment></comment><comment><USER4> Not down with this as a Front End developer here. It's rare that I am able to work along side a developer to understand the structure of his components. Rather we code to a defined spec in HTML/JS/CSS and then throw over the wall for integration with development and back end. This could be near-shore, off- shore or internal - but rarely know before hand.

<comment><USER5> As a front-end developer here, how do you organize your code?

</comment></comment><comment><USER6> The gotcha here is that the selectors in that example SASS file are pretty inefficient. In that screenshot, you'll end up with a selector like ".main .site_box p .name", which the browser is going to parse from right to left. By putting everything behind a class namespace like that you force a potentially unnecessary class lookup on every selector. When you factor in how far nested SASS lets you get in combination with how much CSS a large webapp will require, it can have a large impact on page load speed.

<comment><USER7> _can have a large impact on page load speed_

any data on this?

<comment><USER8> It has a very minor impact:

[http://www.stevesouders.com/blog/2009/06/18/simplifying- css-...](http://www.stevesouders.com/blog/2009/06/18/simplifying-css- selectors/) (Steve is a pretty authoritative source for web optimization.)

tl;dr: avoid selectors that end in * and you should be fine.

</comment></comment></comment><comment><USER9> With so many css and js files you increase the number of requests to the server. It's not optimal.

<comment><USER10> That's why it's suggested you using Jammit (for Rails), or similar asset packager. Django has django-assetpackager. Or you can write your own pretty easily. Scoped selectors makes concatenating style-sheets safe.

</comment></comment><comment><USER11> I'm starting to like javascriptmvc, they've come up with some good practices for organizing code, combining/compressing it, and testing it.

<http://www.javascriptmvc.com/>

</comment><comment><USER12> Great minds: <http://mvccss.codeplex.com/>

</comment><comment><USER13> I used to organize js binding based on the controller (<https://github.com/pivotal/jelly>), but found that it is better to base it on the template.

There are a few reasons:

1\. It makes more conceptual sense. The javascript relates to html (which is generated by the template), not a controller action.

2\. You will probably want to reuse templates across different controllers. Also partial templates can have reusable behavior.

3\. It is easier to move between the associated javascript + template

4\. Refactoring is easier, especially with html gotten via AJAX</comment>


Tariffs China imposes on every country - <AUTHOR> http://thesoundingline.com/the-tariffs-china-actually-imposes-on-every-country-including-the-us/ <comment><USER3> Of course China is playing unfairly. Not many people disagree.

The argument has been that the West should fight China as a unified bloc as opposed to the unilateral tariffs being imposed. It makes no sense to alienate Canada, the EU, Japan, and South Korea when confronting China. All of those countries (and the EU) have serious grievances and would have provided the US additional leverage.

The current approach is rooted in showmanship rather than strategy. It's meant to provide a spectacle.

<comment><USER4> Bill Clinton was very eager to get China into the WTO. Business and Industry and Clinton only saw gleeming $ signs. It blinded them to corruption, unfair practices, etc. They all had been warned about it.

They all thought they knew better and could bring China in line.

After Clinton, GWB didn't even try. He was too distracted by bin Laden. Obama was trying to make nice to the rest of the world during his first term, then got embroiled with the unrest he started in the ME. They had all forgotten about blue collar America. They all thought people would change jobs and these jobs would offer a good living to blue collar workers.

Surprise! It doesn't work that way. Sure your ivy leaguers got nice cushy advisory jobs and consultancy jobs and got to talk about their adventures diring their two year China stint.

All the whole mill workers, garment workers, furniture workers, tools workers were forgotten and left behind.

Now, while inelegantly, someone is finally recognizing the grievance. It's about time. It's a shame it's taken 20 years.

<comment><USER5> > All the whole milk workers, garment workers, furniture workers were > forgotten and left behind.

This is valid point but there is a catch.

Economic growth and progress happens when countries are developing and moving up in the value chain. Developed economies are constantly moving towards high- tech and less labor incentive work. China is still industrial economy. US has moved into postindustrial economy. US manufacturing will decline despite trade wars. Manufacturing work will decline even more than GDP share of manufacturing.

When low productivity work (milk, garment, furniture workers) moves to China it allows redirecting investments and resources to higher value added products.

If these low productivity workers would be zombie/robots, companies would just write them off and recycle them into trash and compost - or sell them to China. But they are citizens and they vote. In other words, we have a political problem.

Possible solutions:

* Use tariffs to protect workers in low productivity work. This moves economic resources in the US to less competitive industries. Over decades, US falls behind other developed countries because it wants to protect industries that developing countries have.

* Solve the actual political problem directly. US citizens not earning living wages with skills they have.

<comment><USER6> Manufacturing output has grown the past many years in the USA - <USER2> productivity technology with fewer workers. It's untrue that manufacturing as an industry is in decline, it's just that the low end has while higher end has risen as have the required skills

<comment><USER7> Some people say that that was an artifact of quality adjustments on computer hardware, and that without the adjustments (or computer hardware) we're actually in a decline. [0] The chart of "Manufacturing" vs "Manufacturing, less computers [1] was pretty striking.

If you sold 1GB of RAM for $10 two years ago, and you sold 2GB of RAM for $10 this year, that's the normal state of the computer market. I don't think it's really equivalent to selling twice as many tons of steel or wheat for half the price.

0: [https://qz.com/1269172/the-epic-mistake-about- manufacturing-...](https://qz.com/1269172/the-epic-mistake-about- manufacturing-thats-cost-americans-millions-of-jobs/) 1: [https://www.theatlas.com/charts/BJh4B5_TG](https://www.theatlas.com/charts/BJh4B5_TG)

</comment></comment></comment></comment></comment><comment><USER5> I'm not a trade expert, but I can spot one clear omission missing from the trade deficit discussion: the value-added.

Chinese exports to the US have significantly lower value-added than the US exports to China. US exports have high value added, over 80% for exports to China. Chinese exports to US have much lower value added, something like 30-40%. Role of third countries in bilateral trading relationships is important.

Extreme case is Chinese made iPhone that leaves very little value-added to China, they just join expensive parts from Taiwan, Japan, South Korea and US together with robots or cheap labor.

China exports more to the US, but less of the value stays in China. If you calculate the trade balance using value added trade US-China trade deficit is $200 billion for combined goods and services.

>0.7 percent of U.S. GDP depends on Chinese consumption of American-made goods and services, while 3.1 percent of China's GDP is derived from U.S. demand. So, in any tariff battle, China would likely suffer more.

[https://www.bloomberg.com/view/articles/2018-07-19/china- s-e...](https://www.bloomberg.com/view/articles/2018-07-19/china-s-economy-is- different-no-recessions-in-a-quarter-century)

Both countries get hurt, but both countries will survive trade war agaisnt each other. But US is not in trade war path only with China. They go against EU, Canada, Mexico and others. Every front trade war would be worse but survivable. The real question is why. Everyone survives trade war but everybody also loses.

> And simple trade models, while they do say that trade wars are bad, don't > say that they're catastrophic.

>To do this right, we should use one of those computable general equilibrium models I mentioned above. These suggest substantial but not huge losses – 2 or 3 percent of GDP.

[https://www.nytimes.com/2018/06/17/opinion/thinking- about-a-...](https://www.nytimes.com/2018/06/17/opinion/thinking-about-a- trade-war-very-wonkish.html)

</comment><comment><USER8> One important thing people miss is that majority of US exports are commodities. Take soybeans for example. Global soybean market has supply and demand balanced. US exports largely to China and Brazil to Europe. Now, due to tariffs China has started buying from Brazil leading to spike in Brazilian soybean and fall of US soybean price. Supply gets re-routed and market comes back to normal. China on the other hand exports finished goods which can't be re-routed. The larger players in the market know this - the Shanghai index is at a 3 year low which the Dow is at an all time high.

<comment><USER9> > majority of US exports are commodities

[citation needed]

according to this (based on CIA factbook 2017) commodities as <15%

[http://www.worldstopexports.com/united-states- top-10-exports...](http://www.worldstopexports.com/united-states- top-10-exports/)

</comment></comment><comment><USER10> I'm not at all a fan of tariffs, but another issue, in the consumer space anyway, is shipping costs - It can be cheaper to ship stuff from china than from the next state.

The whole issue of 'fair trade' is rather complex, as all actors attempt to skew the playing field to their benefit, as invisibly as possible. China appears to be quite good at the game.

<comment><USER11> This is in part because the Universal Postal Union considers China a developing country.

[https://www.wsj.com/articles/this-subsidy-for-china-is- dumb-...](https://www.wsj.com/articles/this-subsidy-for-china-is-dumb-as-a- post-1517963275)

</comment></comment><comment><USER12> Fighting for better trade terms with China arguably makes good sense for the USA.

On the other hand, picking trade fights with close allies & major partners like Canada and the EU is absurd.

<comment><USER13> Trump's not "picking fights", he's getting multiple bids. The American economy is open for business to those willing to give a better deal.

It is literally the same concept as attempting to get as many offers when you sell a house so you can sell to the highest bidder.

<comment><USER12> That doesn't make any sense. The US economy is not a single good that can only be sold once to a particular buyer.

<comment><USER14> I hear Putin wants to buy.

</comment></comment></comment></comment><comment> Engineering-MD These articles on Chinese trade and barriers often mention forced technology transfer and IP theft. Can someone more knowledgeable than me explain the reality of this? It seems that it is such a large imposition I'm surprised anyone does business in China when you know 10-15 years later they will have copied your business.

<comment><USER15> It's taken awhile for companies to catch on. The saga of how the Chinese stole the SU-27 plans from Russia (Licensed the fighter and planned to use Russian components and then switched to Chinese made components after a couple years) is among the ways they do it. [https://en.wikipedia.org/wiki/Shenyang_J-11](https://en.wikipedia.org/wiki/Shenyang_J-11) The Russians were desperate for cash at the time and the Chinese were willing to pay. What the Russians didn't count on was the willingness to straight up steal the design and start manufacturing it in China. Companies have gotten a lot better about protecting their designs now but are up against the Chinese government.

</comment></comment><comment><USER16> this one offers no real data behind the so-called weighted tariff. US and China clearly import different products from each other, different categories of product might have different tariff on each side. Also when China joined WTO they may be agreed to impose some kind of "extra" tariff because it is viewed as developing country

</comment><comment><USER17> I'd be interested to see a graph that indicates the actual amounts, in USD, that each country imports and exports relative to one another.

</comment><comment><USER18> I was hearing this as an argument for tariffs right after Trump started talking about it, but I didn't actually understand it until I saw this.

It's a war of attrition, and we're both gonna lose but china has a lot more to lose than we do atm.</comment>


Instahood — geo Instagram  - <AUTHOR> http://instahood.meteor.com/ <comment><USER2> Awesome, thanks everyone! I built it in about 3 days for a personal project @hackreactor (my first webapp from scratch) and had no idea it was on the front page of HN until just now! haha. Will totally work on cleaning up the interface a bit tonight, wasn't quite prepared for this to see thousands of eyes... haha. Thanks for the comments/suggestions, really appreciate it and totally welcome any more thoughts/bugs/feature requests.

Pull requests are very welcome and appreciated! <https://github.com/michaelglenadams/Instahood>

<comment><USER3> So what were your main reasons for using Meteor, and how did that compare with the experience?

<comment><USER2> Mostly because I had to get something up quickly for our project and Meteor is the best tool i'm familiar with to do rapid development.

</comment></comment></comment><comment><AUTHOR> This app was created Mike Adams, graduate of Hack Reactor dev bootcamp 12 week course in San Francisco, CA. [http://www.quora.com/Web-Development/What-are- the-most-impre...](http://www.quora.com/Web-Development/What-are-the-most- impressive-web-apps-created-by-students-while-attending-coding-schools-like- Hack-Reactor-Dev-Bootcamp-etc)

"My My Hack Reactor classmate Mike Adams' app Instahood is pretty cool. It shows recent Instagram photos from any location you choose. When you first open it, you see photos at your current location. Then you can look at pictures wherever else you want, either by clicking somewhere on the map or by searching for a place (with auto-complete!)

He used Meteor (web framework), the Google Maps API, and the Instagram API."

<comment><AUTHOR> Disclaimer: HackReactor is not a dev bootcamp. It's intensive 12 week in- person course which covers JavaScript, Ruby, Node.js, D3, Meteor.js and other technologies and takes students from 0 to employment: <http://hackreactor.com>

</comment></comment><comment><USER4> Mike's classmate here. It was a pretty awesome presentation he gave on Friday and it was great seeing how quickly everyone's work came together during out personal projects sprint.

Some of us worked on meteor, one did a meteor package, several worked on node, one or two were on rails, mine was coffee and backbone on parse. I love being at Hack Reactor! Building cooler and cooler stuff every week is downright addictive.

If anybody's coming to the next Meteor devshop event, come by and say hi!

<http://www.meetup.com/Meteor-SFBay/events/106842372/>

</comment><comment><USER5> We made this a few years ago - it's a bit janky <http://www.instabam.com>, it's a bit of a experiment of trying to make the iPhone app into a web app.

If you want a free app to find Instagram pics nearby or on Google maps try Instabam [https://itunes.apple.com/md/app/instabam!-explore- instagram/...](https://itunes.apple.com/md/app/instabam!-explore- instagram/id437615875?mt=8)

It was my first ever spare time app and was a lot of fun, it was doing quite well until Apple changed the App Store design, we lost 100 downloads a day instantly after that

<comment><USER6> The meteor-based app seems to be speedier ... maybe because of the way it's handling server-client data relationship better?

<comment><USER7> no it is not (faster).

</comment></comment></comment><comment><USER8> Looking around my smallish hometown area, I'm wondering if social workers and/or police make use of tools like this. I'm not advocating either way, but there's lots of young people essentially publicly confessing to crimes (pictures of them vandalizing, screenshots of text messages about planning to steal clothes from the mall, and plenty of teenage angst). I feel a bit creepy for looking at their pictures, but also shocked they're so revealing to the public. How clear does instagram make it that your photos are public? Is it ignorance or apathy on the part of the teens?

</comment><comment><USER9> I'm a student at the University of Michigan and I just used this in Ann Arbor. Students celebrated St. Patrick's Day today and Instahood did an amazing job collating everyone's pictures from the festivities.

I agree with jgh that the interface isn't the best, but that's something that can be fixed. The underlying concept of seeing everyone's Instagram pictures in your immediate vicinity is extremely appealing to me. Great work and I hope you keep refining this!

</comment><comment><USER10> The interface is kinda hard to use. When I click on a picture and it expands it, how do I close the picture??

Also the "No pictures found" thing is kinda misleading since it just takes a few seconds for the pictures to load

edit: Sorry, I do think this is good...just got thrown off initially cause the interface is kinda clunky.

</comment><comment><USER11> The page was just a black background with white text that said "No Photos" for about 60 seconds before it finally loaded the map/photos. As a regular user, I would not have given it that long to load (without any indication that it's even loading), and would have just left.

<comment><USER2> Thanks for the feedback! I'm looking into the delay issue, hopefully will push a fix soon.

</comment></comment><comment><USER12> Can anyone explain what this is? I see a mostly empty page with two vertical scroll bars and the texts "No Photos..." and "Click on the map or use the search". No map and no indication what I can search for.

<comment><USER13> You have to share your location, then it shows you Instagram photos taken in your area as little Instagram icons on the map, and the photos in a scroll view on the right.

</comment></comment><comment><USER14> Another photosharing website with a focus on geo-location sharing of photos is called Snapr

Check it out here: <http://sna.pr/>

They've also got a developers section with a focus on creating your own sites using their infrastructure. <http://developers.sna.pr/>

(I'm not affiliated with sna.pr in anyway except for sitting next to one of the developers from time to time in a co-working space)

</comment><comment><USER15> Instago does the same thing for iphone and has been out many months.

<http://www.instagoapp.com/>

<comment><USER16> Yeah, but was it created by a novice programmer in 3 days?

</comment></comment><comment><USER17> This really is an interesting piece of software, i can see something like this being used for targeted ads; for example, I see allot of car pictures in my area meaning an ad company could only display car related ads if the user was from my area. This can also be used for stalking. Allot of people take pictures at home and you could be able to find their area by their username.

</comment><comment><USER18> Doesn't work for me, it doesn't do anything even when I share the location. The search is unresponsive. I use Nightly 22.0a1, Windows 7 x64.

</comment><comment><USER19> That looks very cool! At Appvetica we've built a similar thing, we called it Instageo, and it's for iOS check it out: [https://itunes.apple.com/pl/app/instageo-discover-world- arou...](https://itunes.apple.com/pl/app/instageo-discover-world- around/id558489990?mt=8)

</comment><comment><USER20> Great app :) We hacked something similar a few months ago at the Facebook hackathon. It's based on node.js. Feel free to fork. <https://github.com/timurbazhirov/instaheat>

</comment><comment><USER21> This is nice! Congrats!

Feature Request: Filtering via hashtags.

</comment><comment><USER3> Nice hack, but scary at the same time. People are still giving out pretty easy home location data without really thinking about their safety and privacy.

</comment><comment><USER22> Very cool. It would be super sweet if you were polling the API for live updates.

<comment><USER23> Yeah, I'm wondering why this is on Meteor. Is it real-time?

<comment><USER22> Instahood doesn't seem to be real-time

<comment><USER2> It's on meteor, but not really leveraging any of the most powerful features of meteor. I also built it in node but it's not deployed. It is indeed not real- time yet, will get that plugged in soon. Thanks for the comments!

</comment></comment></comment></comment><comment><USER24> <http://RiteTag.com> lets you search words to get Twitter, G+, and yes, Instagram tags that reach topic-following people, those interested in your blog posts, videos, artwork, photographs, and even offers in eBay and Amazon, shows you the when, who, how many times, and what in the content that has been tagged with a tag related to your query, and lets you do a few more things as well. RiteTag is not an SEO tool, its a SSO tool: for optimizing your content in social media to reach more, with relevancy. Some tools do tag illustration: stats. RiteTag is a tool for discovering reaching tags, per network (they vary per network) and learn about tags as well. Its not about optimizingtweets and other content to be seen by those not following you, but following and searching for your tagged topics. Many more networks with topic hashtagging are in the plans for integration, as our first users tell us how they need to tag their photos, images, and goods better to get seen more, and thus sell more. Rather than rush to add every social network with an open API, we focus on relevancy and honing the results in the RiteTag Reports.

<comment><USER25> Soon enough we'll be suggesting relevant and reaching hashtags - even before reports are complete.</comment></comment>


What Your App's Crash Rate Can Tell You - <AUTHOR> http://thecodist.com/article/what_your_apps_crash_rate_can_tell_you <comment><AUTHOR> I like the fact that this is a simple, easily measurable metric that can give you a very good idea of the quality of your application. In fact, I'm now trying to think of what simple metrics I can use to track the quality for the application I'm currently working on (a web application).</comment>


10 (or so) of the worst passwords exposed by the LinkedIn hack - <AUTHOR> http://arstechnica.com/security/2012/06/10-or-so-of-the-worst-passwords-exposed-by-the-linkedin-hack/ <comment><USER2> Since LinkedIn didn't lock my account yesterday, I assumed my password was not leaked. However, LeakedIn has my password marked as 'leaked' but not yet cracked.

Is LinkedIn really on top of this as they say they are?

<comment><USER3> Perhaps somebody else uses the same password as you and they got cracked.</comment></comment>


Delft scientists make first "on demand" entanglement link - <AUTHOR> https://www.tudelft.nl/en/2018/tu-delft/delft-scientists-make-first-on-demand-entanglement-link/ <comment><USER2> "Entanglement forms the link that will provide a future quantum internet" \-- gee, if it was hard to explain to people that entanglement doesn't break the speed limit by transmitting information instantaneously _before_.. yeah we're going to need a simple go-to explanation of what this actually is and how it works.

<comment><USER3> Here's your simple go-to explanation: The quantum internet is a buzzword to extract research money from EU programs. It has no relevance whatsoever for the real internet.

<comment><USER4> I was under the impression that quantum entanglement could provide perfect privacy across a connection, as it would be obvious whether the line communication was intercepted.

<comment><USER5> But you'd need an entangled pair with everyone you want to communicate with.

<comment><USER6> You'd just have to organize daily deliveries from the Entanglement Man.

<comment><USER7> Chances are the Entanglement Man makes 12.00/hr, has to provide his own car and pees into a bottle to make quota.

</comment></comment></comment></comment></comment></comment><comment><USER8> Wouldn't a "quantum internet" have more stable latency? I generally notice that my latency fluctuates between 50ms and 100ms. I attribute this to the other users on my ISP's network, all the routers/switches/etc between me and the server I'm connecting to, and the load the server is under. I assume that the first two things (users and equipment) would be mitigated by using entanglement to communicate. Can someone tell me why this line of reasoning might be wrong?

<comment><USER5> You wouldn't have point to point links with everyone else. You'll still have common trunk lines that get congested.

</comment></comment><comment><USER9> Does there even exist a working quantum network at the moment, as in has anybody ever connected two devices and sent 1MB of data over the link (even if the 2 nodes are only a few meters apart)?

This article is talking about building an internet, but I'm not even aware of a reliably functioning peer-to-peer network, which is surely a needed first step?

</comment><comment><USER10> I'm sorry to sound like the idiot here but, does this mean much lower latency, if so by how much?

Furthermore, how does this make communication more secure? Are you not still sending data from node to node?

<comment><USER11> Information never goes faster than light, even though quantum information does. But, the communication is more secure because the data which goes from node to node is quantum encoded. So if someone would eavesdrop, the code would break and the receiver would immediately know there was an eavesdropper, as he would no longer be able to decode the information. Quantum information can only have 1 sender and 1 receiver.

</comment></comment><comment><USER12> [http://dilbert.com/strip/1992-09-21](http://dilbert.com/strip/1992-09-21)

<comment><USER13> Hehe. Offer he can't refuse. Lol.

</comment></comment><comment><USER14> In layman terms does this mean we will get 0ms latency?

<comment><USER15> Not at all. Instantaneous communication can be used to send messages back in time, so it would be a much bigger deal if that was expected.

<comment><USER16> Can you expand on this? How can it be used to send messages back in time if both are timestamped to the micro/nano second?

</comment></comment></comment><comment><USER17> Off topic: I was in Delft recently on a whim when visiting a friend in Rotterdam. Beautiful old town, highly recommend passing through. And only 10 mins by train from Rotterdam!

<comment><USER18> If you want to visit The Netherlands don't (only) go to Amsterdam. It's like only visiting Disneyland when you go to the US. It's really nice but you don't really get a realistic picture of the country (at least the center).

<comment><USER19> Madurodam was a fascinating day visit. Kidd-ish, but some of the models were fascinating.

Advice: don't drive a car in Amsterdam! :)</comment></comment></comment>