arohner

That only applies to unranked games. Ranked games you'll still lose MMR if a teammate abandons.

Yes, mostly. reader macros are not extensible by the user. The compiler has and uses reader macros.

Rich Hickey has said he hasn't seen an implementation of reader macros that is compose-able across libraries. i.e. two different OSS libs using a two different incompatible macros.

This is part of the Magnuson Moss Warranty Act: https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty...

In effect, the manufacturer can only deny warranty claims for a specific part iff the consumer's aftermarket repair/modifications were responsible for the warrantied part failing. i.e. "I tinted the windows, and now the brakes are failing" does not result in warranty claims on the brakes being denied. However, "I replaced the brake pads [with faulty pads], and now the brake rotors are failing" can result in a denied warranty claim.

Images can load progressively, so pure HTML + one large image absolutely can appear faster to the user. The JS and CSS to load a SPA won't. Page weight is a good rule of thumb, but it isn't the be all end all of a good experience.

Haskell noob here. How is STM used in Haskell? What is type-driven STM?

In Clojure, I don't recommend it because it's Just Another Place To Stick State. It's cool, but provides little semantic value over compare-and-set! on an atom.

Author here. I agree, Timbre is new, and has some rough edges, but in my projects, I've found them worth putting up with. In my current project (18k LoClojure), I think the only serious dependency I have that uses j.u.logging or SLF4J is Datomic. Timbre has an interop library that will pipe java logs through timbre.

I agree knowledge of how Java logging works is still useful, but I'm not willing to be part of the problem anymore :-)

Agreed on Schema, and how it illustrates deficiencies in the type system. I still want core.typed, or something like it, but it's too immature for production use.

This post is true yet uncharitable. The post explicitly mentions a coach, which would lead a reasonable person to assume proper form. Yes, have proper form, but if you're not doing any kind of squats, doing either front or back properly is better than not doing anything.

Shin splints is commonly caused by tight calf muscles and tendons. Try foam rolling your calves and dynamic stretching before a run (google 'runner dynamic calf stretch').

It can also be technique, or shoes. But calves are a good place to start.

Static stretching is probably what you think of when you think of 'stretching', holding a pose for 10-30 seconds. Dynamic stretching is when you move around. Lunges, jumping, calf raises are all examples of dynamic stretching. A quick google for 'runner dynamic stretches' would be informative.

The important part is that static stretching before workouts has been linked to increased risk of injury, and lower performance. Stretching post workout and on non-workout days is fine.

For Clojure Om, there's https://github.com/arohner/foam

Having access to .cljc (clojure files that can be loaded by either CLJS or standard CLJ) helps tremendously here. This means the server-side happens in Clojure on the JVM, so all of the async worries just go away entirely.

momentum. Fuel in the tank. viral. exponential. phase shift. trajectory. lasing. More heat than light.

I've recently had good success writing raw SVG from ClojureScript. What does D3 provide on top of that?

In the past, either the buyer and seller had to wait longer to find a mutually acceptable price, or pay a lot more than $0.10/share. HFT is actually an improvement for both sides, because they can either 1) buy/sell faster or 2) pay lower transaction costs (and probably both!).

Allowing explicit braces fixes deficiencies in python's grammar. For example, multi-line lambdas aren't currently possible in python.

> (Note, though, that serving 2000px wide images to iPhones is fixable in the browser, with downscale on decode.) :)

From a rendering perspective, yes. From a "make this page load faster", no, because the network download time is 10x-100x larger than the processing time.

It's an 8kB async-loaded JS script, and then it posts a small (1kB) amount of data back to my servers. Overhead should be tiny, and it's async so it won't block page rendering.

Shameless plug, but if you care about web performance, my startup, https://rasterize.io provides easy frontend performance monitoring. It tells you how fast users load your site, broken down by desktop vs. mobile, and geography. You can view most of the chrome devtools waterfall information, for every (modern) visitor.

Sure, I'd love browser improvements too, but at the end of the day, you can't automatically optimize everything from the browser. The browser can't magically fix a 1MB JS file in <head>, or serving 2000px wide images to iPhones.

>I'd prefer to just improve the browsers instead of putting the burden on Web authors.

A cynical answer is that Google released this because web authors haven't done a good enough job making fast pages.

You can always upload the .js files to your own CDN.

The other magic of CDNs (aside from the potential cache reuse that everyone is talking about in this thead) is that the user downloads files from a geographically closer server to them than your server. This is typically a huge speed up, and applies even if your JS files are 100% unique.

Depends on your connection. I gave a talk about CLJS page speed, and server side rendering at the recent Clojure conj (https://www.youtube.com/watch?v=fICC26GGBpg). Trying to load my site on the conference wifi, 200kB took 3 seconds = 60kB/s, so 30kB would have been enough.

"Ok, that's not real world". Today, the cable guy is here fixing my home internet, so I'm tethering my iPhone 5s. Loading the .js for my site took 40kB in 143ms = 300kB/s, so 150kB would have been enough.

"Still not real world". Fine. Here's the waterfall graph of a visitor from Canada to rasterize.io today: (https://s3.amazonaws.com/static.rasterize.com/canada-waterfa...). Loading the .js took took 40kB in 60ms = 666kB/s, so 300kB.

So certainly less than half a meg of JS, which is very common to see in SPAs.

Certainly, there are tons of other things that can slow down a site. But the JS is one of the "easiest" to solve, because devs are responsible for it, and it has well known solutions, that people don't apply consistently. (reduce dependencies, only serve one file, Use webpack/closure, use CDN)

If you design your app to use Closure from the start, it's not a problem at all, and as a sibling comment said, CLJS apps get it mostly for free.

The entire JS toolchain lost five to ten years by not adopting Closure. I suspect that in a year or two, someone will release a webpack plugin that does the exact same thing Closure did, with the exact same constraints.

I agree there's certainly some correlation, but we can fix e.g. "slow connections" and "slow computers" by not serving 9MB auto-playing hero videos [edit:] when it's not appropriate for your user demographics.

I'm not in the position to intentionally slow down my customers, so I haven't run a controlled test. Google's test was controlled though.

See my reply to your sibling comment. You can measure very real changes in SEO, user engagement, bounce rate, conversion rate and sales on even small changes (100ms) in page load times. I have personally seen conversion rates vary by 4x based on page load speed.

Google found a 0.5 second delay caused a 20% decrease in repeat traffic, that persisted after the delay went away (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....)

Amazon found every 100ms slower the site loaded, they lost 1% in revenue: http://www.gduchamp.com/media/StanfordDataMining.2006-11-28....

Walmart.com found a very large change in conversion rate based on page load times: ( http://www.slideshare.net/devonauerswald/walmart-pagespeedsl... slide 37)

My own customers have seen 4x different conversion rate, when grouped by page load time. (i.e. same slide as walmart page 37 above, where the peak is 4x higher than the lowest performing group).

Your business probably won't fail because it's slow, but it will certainly make less money because it's slow.

All of Google, and most ClojureScript users would like to disagree with you.

Google Closure has been successfully tree-shaking since it was released, in 2009. ClojureScript uses Closure for an optimization path, so the majority of CLJS apps in production (CircleCI, Prismatic, to name a few) use tree-shaking on every deploy.

Your cache isn't as warm as you think it is. The cache on mobile browsers is ~50MB, and 250MB on IE11. It's smaller on older IEs. Most regular internet users will download more than that every single day.

You should always use a CDN, but that doesn't excuse large libraries.

Shameless plug, but my startup, https://rasterize.io can tell you your cache hit rate for every visitor to your site.

> In practicality how difficult/easy is it to build cross-runtime libraries and how much reuse can you get out of clojure libs b/c of its hosted status?

It depends on what you're trying to do, and whether the platforms help.

Doing something 'pure' like math or datastructures: trivial. Writing a common interface to two different host libraries (e.g. DateTime in JVM & Browser): manageable. Doing something 'host-y', like graphics, with no host libraries in common: very hard.

Basically, Clojure doesn't get in the way of cross-platform concerns, but it might still be a difficult problem.

Idiomatic Clojure tends to have fewer parenthesis than Java.

Yes. I'll also add the 4-year education is incredibly inefficient, in terms of skills added over time. Even in highly technical STEM degrees, you probably don't need 4 years "full time" to gain all of the skills an employer expects a fresh-out-of-school STEM graduate to have. The same is even more true of less technical degrees.

Why is a business checking account so difficult? Seems like "I have $1000 (or 10k) to place in my shiny new account" would be enough to mollify them?