Haven’t tried this one, but I usually delete the Instagram etc. overlays in developer mode.

Try clicking then dismissing the settings thing (cog icon), I had the same issue.

I found it helpful to open it in Incognito, then export it as a PDF.

Any HTTP Server can be easily converted into a HTTPS server by piping it through a SSL proxy. It’s the same protocol going over the pipe, after encryption there is no difference.

Because shifting right by 16 is the math equivalent of “floor” instead of “round”, so we need the result to be not just “as close to 1/3 as possible”, but the error needs to be on the high side instead of the low side.

0x5555 * 3 = 0xffff – shifts right to zero

0x5556 * 3 = 0x10002 – shifts right to one

I’ll add this to the post, thanks!

Because the number 0.555555… is a little closer to 0.5556 than 0.5555. When they say “in binary” I think they mean “in hex” too.

to be fair, java 8 (and streams) had only been out in the wild for 5 months when this was written.

I did much the same but tried to introduce names in the same places as in the original; as relatively idiomatic Java that’s:

public class Triangles {
    public static void main( String[] args ) {
        System.out.println( triangle( 4 ) );
    }

    public static String triangle( int n ) {
        return IntStream.rangeClosed( 1, n ).mapToObj( Triangles::line ).collect( Collectors.joining( "\n" ) );
    }

    public static String line( int n ) {
        return alternating( n ).limit( n ).mapToObj( Integer::toString ).collect( Collectors.joining( " " ) );
    }

    public static IntStream alternating( int start ) {
        return IntStream.iterate( start, i -> i + 1 ).map( i -> i % 2 );
    }
}

You can also go totally crazy, but I wouldn’t recommend it:

public class Triangles {
    public static void main( String[] args ) {
        IntFunction<IntStream> alternating = i -> IntStream.iterate( i, n -> n + 1 ).map( n -> n % 2 );
        IntFunction<String> lines = l -> alternating.apply( l ).limit( l ).mapToObj( Integer::toString ).collect( Collectors.joining( " " ) );
        IntFunction<String> triangle = n -> IntStream.rangeClosed( 1, n ).mapToObj( Triangles::line ).collect( Collectors.joining( "\n" ) );

        System.out.println( triangle.apply( 4 ) );
    }
}

Great, now I want to my own version but I have to work…

Plan 9 had its own assembler and the one in the Go toolchain is based on it, which might explain its use here. Like you I’m not sure why the prominent billing in the title of this post, the actual page doesn’t make a huge deal out of it.

Yea, there are many possibilities that are far more likely than the one they propose.

Simple coincidence is definitely one. Or someone else in the group did a search while connected to the same hotspot, or while advertisers had figured out they’re in the same household.

People often overestimate how random and unique their behavior is. You can often tell a lot about someone based on a few demographics…and can make surprising correlations.

It may be as simple as their age/location/profession to tell you they’re likely to consider buying a projector in the next 6 months. Perhaps they read an article about setting up a movie night, or gaming outdoors, etc.

Quite likely, but ytf would Instagram require microphone access?

I’m guessing the “correct” way of doing this in Java would be to make a List<Object> and then fill it with Integers and other lists. Basically completely sidestepping the type system. This is unintuitive, and so you’re right that this question is probably a better fit for a dynamically typed language.

Alternately, in a language like ML, Haskell, or even Swift, you can use a sum type, where you can specify that the list contains objects that can either be other lists or integers, and have the type checker enforce that they can’t be anything else (unlike the Java example where you could theoretically stick any object in that list).

Interesting thing about this task is that I think static typing in a language like Java gets in the way more than it helps.

That’s what makes it a strange interview question in this context imo, where it seems they’re hiring for a Java shop, interviewing candidates who responded to a job ad looking for Java programmers. Flattening a list is an introductory textbook example in dynamic languages where you can actually write literals like “[1,[2,3], [4, [5,6]]]”. But it’s not really a introductory Java textbook example.

It’s of course solvable in Java, and a broadly competent programmer should be able to come up with a solution in an hour. But I’m not sure it serves as a great fizzbuzz-type baseline filter when hiring for a Java shop. You probably end up filtering more on whether the candidate has previously encountered a flatten function in a different language and remembers the algorithm (maybe they went to a university that had a Scheme course), and/or whether they’re comfortable with doing ugly run-time type things in Java. Which are not useless skills, but there are probably lots of reasonably but narrowly competent Java programmers who would get hung up because it’s a bit of a “foreign” example to someone who works entirely in Java.

Pretty easy in Python too:

def flatten(lis):
    ret = []
    for item in lis:
        if isinstance(item, int):
            ret.append(item)
        elif isinstance(item, list):
            ret.extend(flatten(item))
    return ret

I haven’t used Java in a long time, but I would spend most of my time figuring out how to make a list that contained both integers and List objects.

I think I would start by taking a step back to see if your data are being properly represented by objects. Java is, after all, OO. If you need a heterogeneous collection, it should be typed to store a parent class of the subclasses you want to store. Asking how to collect objects and lists is too abstract; rather ask how do I collect records about single family homes and also apartment buildings that are composed of multiple units.

its the blog post:

This happened not before trying to convince @Unknwon about giving write permissions to more people, among the community. He rightly considered Gogs his own creature and didn’t want to let it grow outside of him, thus a fork was necessary in order to set that code effectively free.

Looks like there was some minor drama in the Gogs world and that the primary developer of that project was away for a while. Since nobody could push changes they forked the project. An issue on the Gogs Github seems to indicate the protects have differing philosophies now.

What you’re saying sounds right to me, as well.

They’ve since updated the article and posted a correction at the bottom.

Yeah, I noobed out, sorry. I wasn’t expecting anyone to really really pay attention here until next week, when I had more content up and was gonna promote it for real. Oh well.

This looks like a project by Lobster’s steveklabnik

There’s an issue for this which is being worked on. Only complicated since it’s derived from another project.

That’s curious. What are the benefits of string representation? I have only seen ints.

I’d answer “no”. They should be represented as strongly typed instances, though probably with the option of giving a custom one - possibly enums with the correct ints would be adequate. Look at spray.io (or its spiritual successor http4s) for a library that I think handles status codes really well.

I would use int only. Because range of the number also matters and int are easier to compare. Check these lines. For example, any code between 200 and 299, including those, is considered success.

Had a similar experience on Android, but maybe it’s only supposed to make a difference in desktops?

In general, I agree with you regarding the intence page.

However, the natural scrolling has good applications in places where automatic scrolling has to happen – especially when 2 dimensions are involved. A project I worked on this summer needed to highlight the relationship between a list and an SVG, and we used automatic (smooth) scrolling to make sure the thing that was to be highlighted was actually visible

Yeah, kinda makes you wonder: if JS is in fact going to take over the world, wouldn’t it have done so by now? JS is butting up against technical limits, and I don’t see browser vendors having any real incentive to push things further. Three of the four major browser vendors (Google/MS/Apple, but not Mozilla) have a major source of income established on top of native apps. That is probably a safer revenue stream than the web can ever be.

(Though from the app economy’s POV, wouldn’t it be nice to reclaim some of the economic surplus being extracted by the app stores? I don’t think it’s possible though, I think app store success is somewhat derived from there being a consistent and optimized way to pay – i.e. a payment system monopoly is a precondition to the current native app distribution success.)

Maybe it would work to build JS a new UI toolkit that is not dependent on HTML (but polyfilled to it). Surely it would be easy to write useful apps in JS if you were targeting a different toolkit, i.e. one not hamstrung by HTML. Android showed that it is possible to write OK user facing apps in Java. It seems within reason to do so in JS as well.

Then again, I think it’s fair to say that any web developer turned app developer that cares about UX enough to switch to a more native language has already done so. And therefore the JS developers that remain have been selected down to those that don’t care about UX as much or aren’t as capable. I guess it’s a question of how many such JS developers there really are.

Huh, I’ve never seen this RFC before.

You could easily change the separator to “/” in the current implementation. However, there is not (currently) an option to remove the wrapper around the keys. I think that the wrapper makes it all more easily grep-able. The RFC also does not address array indices, which makes things a little challenging.

However, adding the ability to remove the wrappers would be a simple enough change to support this kind of format if one chose.

I don’t see FoundationDB hitting the same use cases as an eventually consistent DB. I’m not actually sure what the use case is for FoundationDB. The database does not support multiple data centers and the company actively tries to talk people out of expanding across datacenters[1]. Things that would require the kind of write performance they are offering are going to be pretty big, I would imagine. You wouldn’t host Twitter in 1 datacenter, for example (to take a comparison the author makes).

I think it’s cool that they are achieving this kind of performance. I just don’t understand want problems it’s solving. I would rather have eventual consistency where I can setup clusters around the world and sync them, giving me horizontal scalability of operations, than be stuck in 1 database cluster in one datacenter and have to get as much performance out of that as possible.

[1] http://highscalability.com/blog/2014/11/12/three-reasons-you-probably-dont-need-multi-data-center-capab.html

In addition to the size argument made in a sibling comment, AtomicInteger/Long has a very different API to LongAdder. It is used for counter management because it’s the best construct available for it, but that doesn’t mean it’s a great one.

In particular you always sample when you increment an atomic type (using incrementAndGet or getAndIncrement). This means it must update inline. The adder type, which has a void increment, doesn’t have this constraint, so can defer the synchronisation cost. The actual means of implementation changes the structure’s internal representation enough that it warrants another type.

One potential problem (if it matters to you) is size: LongAdder is a lot bigger. It uses a list of packed AtomicLongs. So if you have 24 cores and high contention, your LongAdder could grow to 24 packed counters. And each counter is packed with 64 bytes to prevent false-sharing along cache lines, which makes them rather bloaty for what is basically a simple counter.

Of course, if you have 24 cores and high enough contention to cause the LongAdder to use 24 counters…you need the concurrency anyway and probably don’t care about the bloat.

If your counter is rare-contended, AtomicLong will be faster since there is a certain amount of overhead to the whole LongAdder setup.