Hacker News new | past | comments | ask | show | jobs | submit | hosh's favorites login

I remember a classic MIT problem set in computer science where we reduced the problem of finding a "profitable arbitrage loop" in a directed graph to a shortest path problem: imagine a graph where nodes are currencies and edges are exchange rates: we're seeking to find some loop of nodes U,V,W,...U such that the cumulative product of the edge weights is greater than unity.

The trick is to transform the graph by taking the negative log of the edge weights, which turns problem of finding a cumulative product > 1 into one of finding a negative sum loop. Then, you can just run the Bellman Ford algorithm and if it detects a negative cost cycle in the transformed graph, this corresponds to a positive arbitrage cycle in the original graph.

I always thought that was a neat application.


I've been reading lately about the properties of lime mortarand concrete (check "building with lime"). I have an early 50's garaje that has rammed earth walls. Because recent covers with portland and plastic paint, the humidity is destroying the wall from the inside.

Amazingly the solution seems to be more breathable mortar cover using lime in the traditional way. This goes contrary against all the recomendations from modern buiding codes.

Lime mortars and concretes are very interesting for not technical (bridges and skyscrappers) applications. Lime cures absorbing CO2 and "petrifying" for months. It has much lower compression strength, but that helps to preserve the stone used to build. When there is thermal or ground movement, the part that breaks is the lime binder and not the rock, making it easier to repare (concrete is so strong that it breaks the whole wall). Also for small fisures, lime is self healing, it disolves with humity and fills the micro cracks. This way you can see this old european buildings that are actually leaning slightly in some direction but holding without mayor failures.

Another advantage is that it's breathable when using it as a wall cover. You don't develope "humity" stains in your wall nor it leaches white salts like the porland cement.

It can also be used to stabilize a road or ground around a house without pouring concrete, specially if you have problems with mud. Just mix a small part of lime for square meter of land, wet and ram. The ground will hold much better heavy traffic and absorb water when it rains. They are using this technique in some southamerican jungle roads as it's cheap and holds well. I've also seen videos of this method being used to improve the ground of factories.

Painting or sculping with cured lime (lime that has been rehydrated and wet for months, to allow it to cristalize). Gives you a sanitizing surface because it's extremely alcaline.

It's not a super material, in fact the structural properties are mediocre compared to modern ones, but the overall advantages are quite interesting for small buildings, decoration, and given that you are roman you could buid quite durable structures.

Very different concepts of how building materials should behave compared with modern materials (more isolation, more strength and stiffness).

About the rebar, I've read some articles about using basalt rebar (basalt glass fibers binded with epoxy). They say it's structurally stronger than steel and not degrading nor corroding. I don't know if it really works.

Edit 1 & 2: typos and formating. Writting from the phone..


Most sources are from restorers of old buildings and lime associations.

Building with Lime: A Practical Introduction by Stafford Holmes et al. Link: http://a.co/3BdZ2tp

There is a book that it's virtually impossible to find: Artes de la cal by Ignacio Garate Rojas, who was restorer of the Alhambra de Granada and several other monuments in Spain.

http://anfacal.org/media/Biblioteca_Digital/Construccion/Mez...

http://cornishlime.co.uk/information/lime-in-building/

Soil stabilization: http://www.graymont.com/sites/default/files/pdf/tech_paper/l...

Hope it helps


It does mention that:

> The famously flat Dutch terrain, combined with densely-populated areas, mean that most journeys are of short duration and not too difficult to complete.

The problem in the US is, in no small part, due to zoning. I've been making my way through this:

http://amzn.to/2tkSbsH - "Zoned in the USA"

And the detailed look at how other countries do things is interesting - they're certainly no "libertopia", but far more typologies of housing are allowed, as well as commercial uses in primarily residential areas.

It's worth a look for those who are deeply interested in the topic.

I actually have quite a collection of articles about this stuff, as it's been one of my main interests lately:

https://bendyimby.com/2017/06/12/yimby-reading/


> Do not fall into the trap of improving both the maintainability of the code or the platform it runs on at the same time as adding new features or fixing bugs.

I don't disagree at all, but I think the more valuable advice would be to explain how this can be done at a typical company.

In my experience, "feature freeze" is unacceptable to the business stakeholders, even if it only has to last for a few weeks. And for larger-sized codebases, it will usually be months. So the problem becomes explaining why you have to do the freeze, and you usually end up "compromising" and allowing only really important, high-priority changes to be made (i.e. all of them).

I have found that focusing on bugs and performance is a good way to sell a "freeze". So you want feature X added to system Y? Well, system Y has had 20 bugs in the past 6 months, and logging in to that system takes 10+ seconds. So if we implement feature X we can predict it will be slow and full of bugs. What we should do is spend one month refactoring the parts of the system which will surround feature X, and then we can build the feature.

In this way you avoid ever "freezing" anything. Instead you are explicitly elongating project estimates in order to account for refactoring. Refactor the parts around X, implement X. Refactor the parts around Z, implement Z. The only thing the stakeholders notice is that development pace slows down, which you told them would happen and explained the reason for.

And frankly, if you can't point to bugs or performance issues, it's likely you don't need to be refactoring in the first place!


Thanks to everyone for their heartfelt responses and interesting viewpoints! Some have pushed back regarding the notion of serotonin imbalance. I would point you to literature that strongly challenges the idea of straightforward neurochemical imbalance as the cause of depression. This is a good place to start: http://kellybroganmd.com/depression-serotonin/

From that article:

> "The most applicable analogy is that of the woman with social phobia who finds that drinking two cocktails eases her symptoms. One could imagine, how, in a 6 week randomized trial, this “treatment” could be found efficacious and recommended for daily use and even prevention of symptoms. How her withdrawal symptoms after 10 years of daily compliance could lead those around her to believe that she “needed” the alcohol to correct an imbalance. This analogy is all too close to the truth."

I believed in the chemical imbalance theory for many years, but now I am persuaded that it's more marketing slogan than scientific reality. This is not to say that antidepressants cannot have beneficial effects. Just that it's not clear that they are correcting any naturally occurring imbalance.

As far as the interesting point that emotions and neurochemical brain states may be equivalent, I grant that this may be true. I guess it was more my way of referring to two approaches to emotional problems: the first, which sees the problems originating in the brain chemistry, internalizing the dysfunction within the sufferer. The second, which sees the brain chemistry mostly as a reaction to the life and environment of the sufferer, wherein the true dysfunction lies. This points people in the direction of their relationships, the congruence of their values and choices, their life philosophy, etc. which I find a more productive pursuit.


It's not required for you to give LinkedIn access to your contacts for them to know you're connected with someone else.

* Your friend may have given LinkedIn access to their contacts and now LinkedIn will start spamming you to connect with them.

* You have a friend-a and friend-b who both gave LinkedIn access to their contacts. You're in friend-a's contacts but not in friend-b's. LinkedIn can assume there's higher than random chance that you know friend-b. LinkedIn will probably try to spam both of you to connect with one another. Why not, right?

* You have a friend-a and friend-b and friend-c who all gave LinkedIn access to their contacts and you're on all 3 but none of them are in each others. LinkedIn will probably try and spam all 4 of you to add each other.

There's prolly plenty more and a team at LinkedIn focusing on just this. Anyone else care to add clever ways to infer connections?


This is pretty awesome, Google is definitely leading the industry here.

One of the more interesting things I learned while working for Google was the intricate way in which the "grid" is managed by a separate but co-operating set of entities. Google disrupted that happy bunch by creating a wholly owned subsidiary that was a licensed power company[1]. That gave it standing to buy from and sell energy to the grid and it completely short circuited a lot of crazy negotiations that were going on between Google and various regional power companies. Now instead of having the substation outside the data center owned by the local power company it could be owned by "Google Energy Inc." And Google Energy could buy energy from any vendor connected to that grid.

Most people are familiar with the 'last mile' problem where the connection to the Internet from your house has to go through the local monopoly utility. The same is true when buying power, and this move on Google's part completely side stepped it.

[1] https://www.cnet.com/news/google-energy-subsidiary-considers...


I came here to say this... Those FRAKTA bags (http://www.ikea.com/us/en/catalog/products/17228340/) are 100% polypropylene (thin strands, even). Polypropylene breaks down under ultraviolet light. The fact that the weave of the cloth is made from fine strands of polypropylene means that it will break down very quickly in the sun.

There's a "fix" though that should be good enough for a camping trip or two! Coat the bag with a powerful sunscreen. I'm not talking about those "SPF 50" spray bottles--those will wear off pretty fast. No, use Butt Paste:

http://www.buttpaste.com/

Yes, it's diaper rash cream but it's 16% zinc oxide which is the primary ingredient in many sunscreen lotions/sprays. Even better, because it's a thick cream it will actually stick to that slippery blue Ikea polypropylene fabric and do a decent job at protecting it from the sun.


I don't think this article adequately captures the problem. I'll try to illustrate.

I explained to my children about the 2 US candidates. I described both of them as bullies and said they promote a culture of bullying. We discussed how they set a bad example for the broader community and how media condones this behaviour.

I was picking up my children from school when one young boy called me by my first name in a mocking tone. I approached him and asked how his day was and took a moment to ask about him. When I now see this boy, he goes out of his way to say hello.

I recently went to a computer club open day. The rules were "we will only allow the same number of boys in as girls". I looked around and saw about 20 boys and 1 girl. I went to this girl and her mother and said "good on you for giving it a go, a variety of experiences is essential to helping you find your true self". The mother went on a sexist rant about patriarchal societies (the usual politically correct thinking) and I said "why would you deny any child the opportunity? Why would you force the same numbers of girls and boys? What's gone wrong in such basic thinking?" She stopped the hardcore feminist routine and apologised. She was big enough to say "no one has ever put it like that, that really makes sense".

The problem with hate is that the Internet has given it a collective voice of monumental proportions. Our community leaders have let us down by selectively promoting prejudice (eg. Emma Watson is glorified for hypocrisy) while aggressively condemning others, especially passive people like Matt Taylor. What's worse is that most people don't recognise hate and bullying when they see it, or they are apathetic to it.

My simple rule: if someone promotes one group over another, they are as bad as someone who excludes or vilifies a group (especially politically correct people who are huge bullies). These people who marginalise are the true haters and bullies. The article really misses the breadth of hate and bullying.

Thought for the day. Do a search on breast cancer websites. How many of these sites do you think alienate men who suffer from the condition? Why do you think many of these sites quote percentages of male victims?


I think the helicopter parenting debate could be reduced to just knowledge of consequences and systemic thinking. The situation you described was an excellent opportunity for you and your playmates to understand the consequences of play style and play environment as a messy real-world system.

This is something you don't get nearly as much of playing video games or going to the mall. So many of our experiences are curated, artificial, and fall far short of the real-world level of complexity.


"The E-myth" by Michael Gerber is the single most helpful book I've ever read on transitioning your thinking from engineering-focused to business-minded. Specifically, the difference between the Technician, the Manager, and the Entrepreneur. I read it on the recommendation of an ex-Google engineer turned failed-entrepreneur, here on HN. He said that a The E-myth described all the failures he had encountered trying to start-up his own software company after leaving Google. And that he wished he'd read it before he took the leap. Do yourself a favor, and pick it up as soon as possible.

I don't indulge in the SUNW autopsy parlor game often, but coincidentally, I've already played it twice today (for the first time in many months), and I'm waiting on a build -- so perhaps the third time's a charm...

Disclaimer: I was one of the ones who tried like hell to right the ship. So I am not only suffering from the same hindsight bias that everyone else will inevitably suffer from, I am further biased by the lens of my own actions and experience.

That said, I think Sun's problem was pretty simple: we thought we were a hardware company long after it should have been clear that we were a systems company. As a result, we made overpriced, underperforming (and, it kills me to say, unreliable) hardware. And because we were hardware-fixated, we did not understand the economic disruptive force of either Intel or open source until it was too late. (Believe me that some of us understood this: I worked extensively on both Solaris x86 and with the SPARC microprocessor teams -- and I never hesitated to tell anyone that was listening that our x86 boxes were starting to smoke the hell out of UltraSPARC.)

Now to be honest, I (and others on the software side) played a role in enabling bad hardware behavior: we spent too much time trying to help save microprocessor management from an unmitigated disaster of their own creation (UltraSPARC-III, cruelly code named "Cheetah") when we should have been more forcefully advocating cutting them off. Personally, I feel I only started to really help the company turnaround when I refused to continue to enable it: I (and we, really) stopped trying to save the hardware teams from themselves, and focussed on delivering innovative systems software. And indeed, the software that resulted from that focus bought the company time and (I believed) an opportunity for renaissance: when coupled with the return of Andy and the open sourcing of Solaris, there was reason for great optimism around 2005 or so...

Unfortunately, it wasn't enough. One could argue that our technological pivots were too late, and they may well have been, but I think that the urgency and focus that we felt in the engine room (aided by the bone-cold water that was at our knees and rising) was simply not felt or appreciated in the wheelhouse: I feel that we could have made it had there been more interest at the top of Sun in the mechanics of running and managing a multi-billion dollar business...

Or maybe it's not so unfortunate: thanks to the fact that we open sourced the system, I still get to work everyday on the technology that I devoted my career to -- and I'm loving it more than ever, and having more fun developing it than I have in a long, long time. (And, it must be said, I'm working with many of the same engineers that made working at Sun great.)

So when I look back on those years, I believe it will ultimately be with fondness, not regret; for me personally, Scott nailed it: "Kicked Butt, Had Fun, Didn’t Cheat, Loved Our Customers, Changed Computing Forever."


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: