no_gravity

Commenting so I can check back in 30 years.

When I look at the big cities mentioned in the article on Google Maps, about 50% of what I see are roofs.

I wouldn't be surprised if we also put roofs on the gaps over the next 30 years. So whole cities become indoor areas.

Living in an outdoor city might become as unusual as it is to live outdoors today.

Additional guess: Most of the roofs will be made of solar panels.

    I’ve found a pretty simple starting point for
    testing the bones of a website by using the
    following single line of CSS:
    
       * {
           border: 2px dotted black;
       }

Another nice way to find obsolete elements is to simply type this in the console:

    $$('*:only-child')

Elements with only one child usually can be optimized away. For example here on HN, it shows that every <code> element is wrapped in a <pre> element. I would think the same could be achieved by just setting the right styles on the <code> element.

Upon closer inspection, I now see that the Show HN also has additional empty lines in the rendered view.

End of the source:

    </body>
    </html>

Rendered in the browser as:

    </body>
    
    </html>

Then the empty lines that are in the source are missing in the output. Looks like the Show HN avoids this by not having empty lines in text.

Tried to replicate the technique in a minimal example:

https://no-gravity.github.io/html-quine/index.html

I am getting some additional empty lines in the output. And the closing html tag is missing. Any ideas why?

I think it is best to design your own captcha around your use case. All you need to do is make the amount of work for spammers too high for targeting your site.

Just recently, I added the idea of a captcha that might actually be enjoyable for users to my list of "things that should exist":

http://www.gibney.de/things_that_should_exist

The idea is to show the user a random image and ask what is on it. If the image is beautiful, that might even be fun. And there are many sites that offer beautiful public domain images. And have tags for everything in them.

There probably are many other funny and enjoyable captcha ideas one could implement.

Put this in your bashrc:

    source /usr/share/bash-completion/completions/git

And you can type "git br<tab>" to write "git branch", "git checkout fun<tab>" to write "git checkout funky-feature", "git log --na<tab>" to write "git log --name-only" etc.

Pretty much every time you press <tab> somewhere while writing a git command, it does the right type of completion. And hitting <tab> multiple times lets you toggle through the options. So you learn git along the way.

This was one of my most enjoyable productivity jumps when it comes to using git.

I think this is putting too many different functions into a single command.

    uxy ls

This looks like it "tabifies" the output of a given command. Aka it turns the output of the given command into a tab seperated format.

    uxy reformat "NAME SIZE"

This seems to collide with the above since "reformat" is not a command which will be tabified. Instead it filters stdin for two columns.

    uxy align

This seems to do the same as "column -t".

    that's because the native widgets haven't changed much

So why aren't they updated?

If browser makers can't maintain something as simple as a radio button, they will probably not be able to maintain more complex widgets.

Browser engines are already so complex that even a giant like Microsoft gave up on maintining one. And Firefox is spending over $200m in software development per year to keep up.

There are two problems with adding widgets to browsers:

1: Once they are in, you have to support them forever. Or you will break the few websites that use them.

2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button.

I think it's better to get the basics right instead of building more and more 'userland' type of functionality into the browser itself.

Does the calculator really use the word "significant"? I don't see it. I am not sure how to interpret the language it uses.

As for going with the winner: Yes, if the test result (39/28) is the only information you have and there are only two choices (go with winner / go with loser) then it makes sense to go with the winner.

    What you've tested using that invocation is the
    null hypothesis that the underlying probability
    of 39/67 is 0.5.

Isn't that equivalent to my interpretation of the test result? "In a world where it makes no difference which design is used, you would get a result as significant as this 22% of the time".

    If you want to perform a test of a difference of two proportions, you need to do:
    prop.test(c(39, 67), c(total_group_a_impressions, total_group_b_impressions))

Do you mean c(39,28)? Because group_a had 39 hits and group_b hat 28. Doing so with the group sizes Bemmu stated (3000/3000) also gives me a p value of 0.22.

As long as the group sizes are equal, the test is not very sensitive to the sizes.

The statement I see on that page is "There is a 91% chance that Variation A has a higher conversion rate".

I am not sure how to interpret that. We would have to dive into the GitHub repo and figure out which test it performs I guess.

    During this time there were a total of 67 new
    subscriptions. Of these 58% (39) came from the
    new design and 42% (28) came from the old design.
    Looks like the new one is a clear winner.

Is it? This seems a small population to settle on a clear winner.

Using R's prop test, I get a p value of 0.22. (Type "prop.test(39,67)" to calculate it).

I think this means that in a world where it makes no difference which design is used, you would get a result as significant as this 22% of the time.

An alternative is the Adjusted Wald method. You can try it online here:

https://measuringu.com/wald/

Which gives some confidence intervals which also range from "could be better" to "could be worse". Even when you reduce the confidence level from the typical 95% to 90%.

    a quick check with an A/B testing calculator
    even says that this result has significance
    (~90% likely)

Which calculator was that?

One reason is that SPF already accomplishes good enough sender identification without any hassle on the user side.

When you get an email from joe@example.com and example.com is trustworthy and uses SPF, then you know that the sender in fact was joe@example.com

It's easy enough to set up SPF for any domain.

Gmail, Yahoo, Outlook etc all use it.

    Randomly initialized life quickly collapses
    into stable structures, most of the time.

Is this true? That would be a very profound finding. Any papers that discuss this?

Looking at a random game of life with 10^6 cells, I get the feeling that it will not loop for a long time.

Maybe it is a misunderstanding. I do not mean to find a self-replicator of size c in a field of size c. I would expect that the field is big. Very big. Let's say 10^80 cells. That is the estimate for the number of atoms in the universe. The self replicator would be way way smaller. One manually constructed replicator (Gemini) is just 10^7 cells. And that is certainly not the smallest replicator possible.

I wonder if there are estimates out there about how long a randomly generated game of life instance of NxN cells will take until a self-reproducing structure appears. An event that we have not witnessed so far.

Somehow I feel it is related to the question how likely it is for a planet/galaxy/universe to breed life. An event that we have "witnessed" just once so far.

One way to divide it into two estimates:

c = Number of cells of the smallest possible self-reproducing structure

i = Number of new structures that are created on average for each iteration

Then a rough guess could be that it takes 2^c/i iterations.

I have written out my theories on the expected and observed behaviour on the page now. I also added a link to a long discussion this spawned on lobste.rs which is pretty interesting.

    if you were expecting red also to be printed

I did not expect that. I expected the output to always be "blue green".

The surprising thing here is that about 1% of the time, the command outputs something else. It seems to be some race condition that happens in the handling of the pipeline.

Looking at the problem from a game theory perspective, it looks like this to me:

Ambitious people want to live as close to as many other ambitious people as possible. So wherever the density of these 'Hipsters' or 'Cool People' increases, the desirability of the area increases. And by law of supply and demand, prices go up.

The willingness and ability to pay higher rent decides who can live in those 'cool areas'.

Now the 'cool people' might say to the landlords: "Hey, it's US who make this area cool! Not your houses! Why do we have to pay you for it?".

It's an interesting point. Is it fair? I am not sure. Maybe. The same argument could hold for Facebook, YouTube or Reddit. It's the users that create all the value. Yet the platform providers extract most of it.

I think that before we can form an opinion on different types of regulation, we should ask: If not willingness and ability to pay rent decides who lives where - what or who will decide instead? And what will be the result?

Sorry, I did not keep the file. I still have the 3 replacement commands that created it in my vim history though:

    %s/[^0-9]\.//g
    %s/(/-/g
    %s/)//g

Oh yeah, I overlooked the parentheses when cleaning the data with search+replace. Thanks, fixed that now.

As for the log scale .. I'm not sure if that is the right choice.

Agree that it is not easy to interpret.

I could add a log scale chart, but since the value is the annual percentage change of market value, I think a linear scale is the right choice. But I'm not 100% sure. Would like to hear some opinions on this.

On the first page is a nice table with the yearly performance data of Berkshire versus the S&P 500.

I wanted to see it as a graph. So I cleaned it up in VIM and then made this chart from it:

https://www.productchart.com/blog/2019-02-23-berkshire

Customizability of the web is a pet peeve of mine. And I wonder if selecting the color of text and background should really be a function of the website that the text is on.

There is no technical reason why not everybody should be able to set the color for any website any way they want.

I would expect it to be trivial to make a bookmarklet that changes the color of HN. Here is a quick hack that makes HN display green text on black:

javascript:(function(){s=document.createElement('style');s.textContent='*{color: #0a0 !important; background: #000;}';document.head.appendChild(s)})()

Just edit any of your existing bookmarks and put that line into the url field. Now whenever you click that bookmark, the current page turns into green text on black background.

What I find interesting is what he says he loses by doing so.

60000 followers.

No word about losing business. Or interesting discussions. Or inspiration. Or meeting likeminded people. Or getting feedback. Or anything.

I think many people come to this conclusion over time. That the number of social media followers is just a number. With little to no real world impact.

When we play a computer game - say a racing game - where is the mass hidden, which pulls the cars downwards?

Wordpress is a tool to make websites. Yes, you can put your content on a website and then link to that from Twitter.

But that puts a big barrier in front of your content and the Twitter users. Visiting a website is usually a horrible experience. So people are very hesitant to do so. Click through rates from social media to websites are abysmal.

The main problem I have with Twitter is that when you reply to your own tweets, the reply will appear as a new tweet on your timeline.

This way your timeline becomes total chaos. Unless you only tweet a single 280 chars text and never add anything to it.

Otherwise, I would use it to post topics I am interested in. Reply to those topics to add more text or when new information becomes available. And have a discussion with people interested in those topics. I wish there was such a platform. It would be like everybody can run their own mini HN.

The slide says by 'TypeScript'. Not by 'Types'.

So the static code analysis of the typescript compiler would have catched the bugs.

Without examples of those bugs it's hard to say if types play a role here.

It could very well be that most of these bugs would have been prevented by any static code analysis. Independent of the usage of types.