mark242

The match is just my personal preference to deal with option types, because I personally think it's cleaner to read. This reduces the number of flatMap chains in my code, but again, personal preference.

  Option(JavaClassFactory.staticMethodThatCanReturnNull()).map(i => i + 1).getOrElse(0)

This is a very readable function, imo, and is how 99% of Scala programmers deal with legacy Java libraries. Scala even has the Try() object, where you can do something like this:

  Try(OldJavaClass.methodThatThrowsExceptions()).toOption.map(i => i + 1).getOrElse(0)

It makes creating service-layer code so much simpler because you aren't caught in that rut of "well now I have to deal with this exception at the controller level". You can head off all that garbage very quickly. I suspect that a lot of Java Optional coders will start acting like this.

Your very first method has a return buried in the middle of your code. That is a gigantic red flag.

Look, what you're trying to do is simple.

  getNumbers.fold(println("Failed to load numbers"))(nums => nums.foreach(println))

That's the Scala version, but I'm sure there's a Java version of the same code. This code assumes that getNumbers returns Option[List[Int]], which your compiler can guarantee. If you want something that's a little bit more readable, try this:

  getNumbers match {
    case Some(nums) => nums.foreach(println)
    case None => println("Failed to load numbers")
  }

No null check, no loops, just very simple easy-to-read bulletproof code. This code cannot generate a NPE at all, ever.

Option is a takeoff of the Null Object pattern.

Option(null).map(str => str + "!").foreach(str => println(str)) is a noop.

In Scala, you're encouraged to write more bulletproof code by avoiding exceptions at all time, simply because it's easier to realize that (in your case) getSomeRiskyNumber returns an option instead of an integer.

  getSomeRiskyNumber map {
    case Some(i) => Map("risk" -> i)
    case None => Map("error" -> "Error retrieving number.")
  } map { response =>
    Json.toJson(response) 
  }

Reading this code you know you're always going to generate a json response to the user, and depending upon what getSomeRiskyNumber() returns, the json response will either look like { "risk": 23 } or { "error": "Error retrieving number." }. No exceptions needed.

A flexbox "column" can also be a row. You can have a container item centered vertically and also have it include two items.

Obligatory "did you try running sbt ~ compile before you started complaining about the compile times" post.

It's amazing how the tools for faster turnaround times exist-- the one thing the Scala community needs to do a better job of is clear, opinionated documentation.

Also -- https://github.com/scala-native/scala-native -- watch that space.

I don't understand how lines 4 and 15 don't get caught by the compiler-- a String cannot extend an Integer?

I'm not even sure how you would be able to write this in Scala without violating rule number 1 of Scala, which is "never write the word null in your code".

+1 recommendation for The Great Suspender. Works like a charm, noticeable difference on overall system performance.

Just anycast cdn.ampproject.org to a cluster sitting on your network with Google's supervision and cert? This is added value for the provider, just like sticking a bunch of Akamai boxes on your network is added value.

Okay but let's be realistic-- you are not a major publisher trying to make money off these pages. You can say "yes my page loads in 100k and 300ms until DOMContentLoaded" all you want, that doesn't change the fact that when you slap a couple of pieces of advertising on there, it's going to slow down.

To give you an idea-- the New York Times page without any advertising on it is 2MB and has a DOMContentLoaded event at 1.29s, approximately 1 second slower than your page. With advertising, it is 3.9MB and 1.82s.

When ad networks are able to run without almost 2MB of Javascript, then we can talk about how AMP isn't needed.

Sure. AMP is a good thing. Google is simply the first company to implement the AMP cache-- Cloudflare has recently spun up their own and outbound links from Cloudflare-enabled sites can use an AMP cache that doesn't rely on Google, so they get the speed benefits as well.

The implementation of AMP is one of those technologies that's "the more it gets deployed, the better it is." Reading the spec, it's clear that Google's vision is for AMP to be the opposite of FB instant articles; where the entire web can have a decentralized cache (yes this sounds weird but makes sense). I suspect Cloudflare will help quite a bit with this.

I could see mobile networks implementing their own AMP caches, so their inbound traffic winds up terminating mostly at the cache layer. This speed boost will win the mobile networks customers.

"I dont have a fixed telephone number anymore. How to handle that?"

Get a fixed telephone number.

"My inner tin foil hat says Google wants a phone number for other purposes."

"I already have an Android phone with Google Play Services installed."

Guess what - Google already has your phone number before asking for it via the 2FA form. My guess is that the reason they have one platform-independent process for setting up 2FA is for iOS users.

This rant is exactly why phone numbers are a good way to do two-factor. The author lost control of their phone number ("as i quit the account shortly...") and subsequently had an extremely hard time authenticating to their bank, Google, Twitter, etc.

Getting a new phone number set up is time consuming, even with a Twilio-like service. This is a good thing. Your IMEI number isn't portable, and until there is a physical token on your phone that is also portable, a phone number is the next best option.

Here's the important piece of information, from the conflict resolution page:

"Compare their string values with JSON.stringify, choosing the greater of the two."

In other words -- don't ever use this database in production.

on edit: Here's why. CouchDB, which is also an AP database, puts conflict resolution into the hands of the user, but each document contains a revision, including information for the user to determine which is the correct revision. Many times, it's just "the correct one is the most recent one", but that's done in the user's code.

Making this kind of assumption (stringify and string comparison) for conflict resolution is dangerous because there will be scenarios when you will lose data no matter how many times you post to the database, guaranteed. Yes you can't be consistent, but you need to tell the user that there's a data conflict and have them deal with the logic.

If a promise in the array is rejected, Promise.all (which returns a promise) rejects with (supposedly) the first rejected promise, but that's extremely hard to predict if you have two promises which could reject.

Serializing a promise to localStorage; I get what you're trying to do, you want to have a worker pick up exactly where it left off when you left the app. This is where a service worker would help you. I suppose you could write some kind of durable mailbox a la Akka, only running in the browser.

Yeah, look into using Promise.all. You're probably looking at a good few hundred lines of code reduction. What you're describing as a "command" (request / state update) is just a promise with a map function applied. Your "simple queue thing" can just be an array that you fire Promise.all at.

I suspect that using Promise.all() helps greatly with this.

Here's your user assumption: 99.8% of browsers have Javascript turned on. Creating a fallback version of your app that works without Javascript is basically like developing for IE 5 -- you are completely wasting your time.

Here's another one: mobile browsers make up a majority of web traffic now, and Chrome and Safari are pretty well split in terms of share. Sending HTML tags over the wire is a waste of your users time. The idea of "progressive enhancement" should be thought of more as, "what can we display quickly on our user's screen while we're downloading and parsing the Javascript to make the application work". Note that this doesn't mean loading screens, just an initial state which shows the user progress in building up the app from that initial http connection. Regardless of the negativity around AMP, Google has made us think about what exactly we need to do in order to provide a good experience quickly and a feature-rich experience within a couple of seconds.

tldr: Someone wrote a bunch of paragraphs and LOC around JSON.parse(window.localStorage.getItem(key)).

If you're really interested in learning about creating a workable offline web app, Google has some great documentation. https://developers.google.com/web/fundamentals/instant-and-o...

Last, the Safari team needs to seriously get to work on Service Workers. We will see web apps grow by leaps and bounds once the service worker spec is opened up to iPhone users.

Those cane fields on the way from Kahului to Kihei, while beautiful, seem like a massive wasted space. I like the idea of a decently-sized solar farm to replace the power plant just above Kihei.

Beef is very plentiful on Hawaii - there is a large amount of history about the paniolos, basically cattle ranchers on the Big Island and Maui. Parker Ranch, on the big island, is a huge supplier of beef. http://parkerranch.com/

Didn't they switch to the subscription model because people weren't upgrading enough to sustain the business?

I still don't understand why, after having grown to a sufficient size, Reddit doesn't just enforce two-factor at account creation time. Tie a user to a phone number at the very least.

If you were ever wondering why Google started AMP, this is it. 5k+ LOC of inlined Javascript, 2.6MB of data and a 13 second load time.

From the post:

"Well a big one: Privacy of the readers of Pepper&Carrot."

Before even thinking about tossing things like Google Fonts or AddThis or whatever, the very first thing you need to do is turn on HTTPS. If you're concerned about privacy, or content injection, or MITM attacks, or name-your-poison-here, you must immediately only serve up pages via HTTPS with strong encryption.

Quick feedback for the AWS team:

* First, this is great. The simplified interface vs EC2 is terrific. This is the direction EC2 (and RDS and S3 and basically everything) needs to be going.

* Instances you start in LightSail don't show up in your EC2 console. I would expect there to be some kind of data sharing there.

* Similarly, creating a "static IP address" doesn't show up in your elastic IP list. I'm not sure if this is intentional, but to manage two different views of products that you're billing me for is... troublesome.

* Last, if I could migrate elastic IPs from EC2 to LightSail I'd be migrating all of my instances immediately. The bandwidth savings are massive. (Related: when is the 2TB limit for a t2.small going to be migrated over to EC2?)

on edit: There are so many of these companies that are basically stylized versions of Alibaba listing pages or are basically re-skinning of some business process that, turns out, doesn't actually need to be disrupted. Transporting gasoline to fuel up someone's car? Really? We're going to be energy wasteful just to shave 10 minutes off someone's week?

The other disturbing thing is how many of these gadgets are IP enabled. I really hope YC has some kind of IoT advisor who insists upon security at a low level.

You misspelled "Hibernate". Hope this helps.

If the Secretary of the Treasury designates China as a currency manipulator, your new iPhone will wind up costing you $2000. What madness.