joemoon

Spidey senses going off here. The first two comments read like an LLM.

Thank you, this was a very interesting interview.

While the post didn't particularly speak to me, I think you are being overly reductionist. You can dismissively summarize anything into a few "key points."

Just in the first couple of paragraphs alone:

- The author discusses the "why" by pointing to research on how new information triggers dopamine pathways. Maybe this is obvious to you but it's not necessarily obvious to everyone.

- The author points out that this would have historically been an evolutionary advantage (at least that's my interpretation), but access to modern high-volume, low-nutrient information has made this an addictive unhealthy habit.

- For those already familiar with how modern access to high-calorie, low-nutrient food (that triggers the dopamine response), the author is showing that the same mechanisms are at play with information.

I think it's actually your comment that contains the tweet-able one liners (as "key points") that are likely to result in head nods and smug self assurances but aren't doing anything to encourage deeper thought.

It's definitely a very similar method but fundamentally different in that the 'Distilling step-by-step' approach is a multi-task model.

As I understand it, rather that training the smaller model to produce the CoT/rationale as a part of the (decoded) response, it actually has two output layers. One output is for the label and the other is for the rationale. The other layers are shared, which is how/why the model is able to have an improved "understanding" of which nuances matter in the labeling task.

While sleeping? This is one of the signs of sleep apnea.

Thank you for the anecdote. It was well written and I think it’s very applicable to the current topic.

I suggest integrating this with every single help desk software you can. They all provide integrations. We were looking for something like this earlier in the year as it pertains to customer support and using SMS as a channel.

If help desk isn't the answer, then maybe another type of platform. Generally, I think you need to ride the coat tails of larger platforms.

(Note: I do realize this is developer focused today, but it didn't necessarily need to be.)

I strongly disagree with the sibling comment. Your website _does_ matter. At least in so far as it represents how you are positioning yourself to your clients.

Your website is all about what kind of software you can build. Your clients don't care about that. They want to know what kind of business value you can deliver. What kind of results can you achieve?

As a business owner, I don't want to see example websites, I want to see a case study about how you increased revenue by 20% with a new user onboarding process. I want to see how you saved 100 hrs per month in staff time (i.e. expenses) with the new set of automation features you developed.

If you don't have this data from past projects, then start collecting it. Start framing all of your conversations this way from now on. If a client is working toward a business objective, help them achieve it and make sure you put mechanisms in place to measure success and assign a real dollar value to what you helped them achieve.

Adding keywords: ruby, rails, devops

Just an FYI, it's the "CAN SPAM" act: http://en.wikipedia.org/wiki/CAN-SPAM_Act_of_2003

I thought it was a typo the first time you typed it, but I thought you should know when I saw it a second time.

This is incorrect. The conversion rate does not affect your quality score: http://adwordsagency.blogspot.com/2008/12/quality-score-fact...

A "conversion" means different things to different companies. It would be extremely easy to game the system if conversion rate affected quality score.

You're taking your own opinions and applying them to the entire target market. Just because you feel this way doesn't mean that everyone else does, and it certainly doesn't imply that "updating the site wouldn't make a dent".

They actually do send an email alert. I didn't find an authoritative blog post on the subject, but here's a post from a reputable SEO site discussing these email alerts:

http://searchengineland.com/google-warning-more-about-bad-li...

I just wanted to chime in and say that I also found the popup very disruptive and annoying. I didn't download the ebook. I bet putting it at the end of the blog post will get you better results (you should A/B test it and do another blog post).

After all, the people that read all the way through the entire blog post are your target audience. These are exactly the type of engaged readers you want to capture.

This is called Negative SEO. Matt Cutts discusses the topic here: http://www.youtube.com/watch?feature=player_embedded&v=H...

I'm a day late, but it seems that nobody has answered your question. Here are some things you could have done differently:

- Have a vesting schedule for your equity. This way if things go south, you'll have a certain portion of your equity vested. - Negotiate a higher equity stake in the first place if you're playing such a founding role. In my opinion, if the product didn't exist before you joined the team, then you're a founder. Remember that we're looking at this with the benefit of hindsight. - Made the agreement up front that you had control over the technical decisions since you have the expertise to make those decisions.

I think you skimmed the post. The memo is to his employees and he specifically addresses whether or not the advice is applicable to non-entrepreneurs (spoiler: he thinks it is).

I don't necessarily agree or disagree with the advice, but it's clear that it is intended for "people who do the actual work".

You misunderstood the comment. Angersock is saying that the networking equipment cost more than $5k and the friend was unwilling to buy a UPS to protect the equipment.

On a related note, this plugin has been invaluable to me in the past: https://chrome.google.com/webstore/detail/lazarus-form-recov...

You need a simple narrative. Example:

Sally learns best by doing X, while Sam learns best by doing Y. (Show cartoon Sally doing X and cartoon Sam doing Y). Most apps will try to teach Sally and Sam the same way, but the TommyTeaches app is smarter than that! Tommy will be learning as he teaches. Tommy will learn which techniques are best for Sally and Sam individually, then tailor the lessons to... etc.

> I don't see that as a justification for limiting the expressiveness of a language.

That's a straw man. I never said that the expressiveness of the language should be limited. There are plenty of languages that are just as (more?) expressive than CoffeScript without the syntactical ambiguity.

> If you take that line of reasoning too far you end up with Java.

That's the slippery slope fallacy. I am in no way suggesting that CoffeScript should have completely rigid syntax. Surely there is a happy medium between CofeeScript and Java. There are plenty of languages that live there.

> Just because you CAN do something in CoffeeScript doesn't mean you SHOULD, or should ALL of the time. Just like in JavaScript where, if you want, you can write all of your code on one line, but you shouldn't.

Isn't this precisely the problem? Why make a better Javascript then make the same mistakes as the original? One of the main goals is for Coffeescript to be more readable that Javascript. Having ambiguous syntax and so many different ways of doing things means that people will write code in all of these different ways.

Your rebuttal is a long list of what you SHOULD and SHOULDN'T do, but there are two problems:

1. Not everyone will agree with you.

2. People will write it the "bad" way anyway.

Ultimately this means less readable code, especially when you have to read someone else's code.

> if the browser can't support that, then it's the browser's fault

If you're creating a subpar user experience, then it's your fault. You can blame the webview all you want, but your users are going to blame you.

> then estimate a safe floor I feel the egg won't break at

This isn't a solution to the problem. Your approach carries the risk that you never find the answer (given the preconditions). I don't think this qualifies as "good" critical thinking, since you don't actually have a solution.

I just want to echo want apike is saying. There are several comments here incorrectly stating that this much javascript doesn't matter. It seems pretty obvious that those commenters have no experience developing mobile web apps. Loading jquery is a huge hit, taking anywhere from .5s to 1.5s to initialize, depending on the device and what else is eating up resources at load time.

It's more like 800-900ms. Here is a link to the jquery init time on Android: https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDd...

I don't recall when this kind soul made this document public, but I believe it was in a similar discussion on hacker news and I've had it bookmarked since.

I have also done my own tests, and the iOS numbers are similar (depending on the device of course).

I use the evoluent vertical mouse for this reason: http://www.amazon.com/Evoluent-Vertical-Mouse-Right-Handed/d....

It has been fantastic (though I have the 3rd gen model).

Friendly criticism:

The background are really distracting (and not very aesthetically pleasing). There is not enough contrast with the light colored links. These two things combined make the whole sight difficult to read.

> both of which may be improved on-the-fly (e.g., code-on-demand).

It's funny that your'e using this quote to prove your point, when it actually identifies the perfect example that you're looking for.

Image that we have a relatively "dumb" client that can only understand our media type and follow URLs to the next resource. We already agree that this is useful when you have an intelligent actor (human), so let's move on to the part that your'e interested in: "improved on-the-fly".

Let's take our dumb client and add one feature: A Javascript engine. This gives us the "code-on-demand" that Fielding referenced. You can now improve your dumb little client, by adding application logic that can be executed on-the-fly. Your client can now be upgraded to understand new media types, or to change the behavior of interaction with existing media types. And yes, this means the client can be upgraded even when there is no human interaction.

Want a real world example? I recently wrote a javascript application that automatically runs a set of comprehensive tests on HTTP requests (and their caching properties) and collects the data. I was able to turn the dumb client into a smarter one (for my purposes). It has a single entry point and programmatically follows many different kinds of links. My tests run on approximately 1 billion clients, and I didn't have to update any client software to make that happen. If I want to check the cache behavior of resources behind my business partner's proxy server, guess what: I can upgrade his client (his browser) on the fly to do the testing for me.

Want another real world example? We used javascript in a webview (dumb client) on mobile platforms to create unit tests for some native functionality. Our dumb client happens to have a bridge to the native code on the mobile device. This allows us to write one set of unit tests in javscript and run it on multiple mobile platforms. This is a great example that falls outside of the standard desktop web browser examples.

So let's take a look at your example. > In either scenario, the non-human client is just as hard-coded as the other--it's either jumping to external URLs or jumping to internal links.

We were smart enough to develop a dumb client that can execute code on demand. Now let's upgrade our client to validate the input fields _before_ POSTing back to the server. Bam, we just improved our client on-the-fly, without modifying the client software.

So you may be thinking: But how useful is this to me? If I'm developing a new network-based business analysis tool for my company, it's probably not going to run on 1 billion clients. Do I really need to consider hypermedia as engine state and on-the-fly updates? Well no, of course not, that would be overkill. As Fielding put it:

"REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them."

No, I think you're right. I'm pretty sure strictfp is misunderstanding REST.

TO answer your question (though it may have been rhetorical), the way the client consumes the service has no bearing on whether or not it is RESTful.