halisaurus

I come from the other side of the glass. My toddlers have iPads and constantly tap ads that are usually larger than real, in-app actions. Often the ads are interstitial between two game screens, or float next to the content they are interested in. Besides being frustrating for the kids, I have to be vigilant on the content of the ads they're seeing. From my experience, the ads are not always appropriate for kids. I really wish Apple would offer a "No Ads in Kids Apps" policy.

In case anyone wonders why this isn't a pull request and instead a published fork...

Obviously @mdo can write whatever he likes on his projects, and it doesn't feel right to "correct him" with a pull request if that's how he chose to write the resource.

In the original HN post[1] there were a couple of comments about how some people might want to share this with kids who are learning to code. If they want to share the knowledge without a couple of "bad words" spoiling it now they have a way.

[1] https://news.ycombinator.com/item?id=7457132

The instance that irks me the most is Fast Company, more specifically m.fastcompany.com. The subtitle that's highlighted in yellow loads the BG color before the font is loaded and line-height is calculated, so on mobile there's an empty yellow block that then separates and then gets filled with text. For a site/magazine focused on design it's one of the uglier things I see on a regular basis.

That this is missing is surprising. This method is the most compatible across browsers and only real drawback is the additional markup.

I'd wrap this into a single HTML/JS snippet with something like [PUT_YOUR_USERNAME_HERE]. Style it to show the last tweet in Twitter's card style. Show that on the site and anyone can use it, even without knowing what a GET request is. Drop a credit link to your site at the bottom. This is the simple stuff that is useful to non-technical bloggers and Tumblr-ers.

Why not both?

For one, setTimeout is pretty run of the mill. If you haven't come across a situation where you need to wait a period of time before initiating some event, you simply haven't coded much. If someone else had just nailed the question in the interview before him than—hoop or not—they've proven a skill he hasn't.

Even if we ignore this, the "What Really Happened" area sounds like he only admitted he doesn't know, and worse, that he doesn't know how to proceed. Another comment above asks if one small set back is really a deal breaker, but in my opinion, not attempting to overcome a problem you haven't seen before shows more about a candidate's abilities than simple knowledge. Prove you can find a solution when all you have is a basic idea of the problem. Take a hint and run with it. (The interviewer gave the method name as a hint!) Google the answer.

This post hints that the position was closer to entry level, so I would suspect that curiosity and autonomous problem solving are fundamental requirements for the role. When you're green a lot is going to be brand new, so you have to be able to learn on the spot and run with it.

How often are the cashiers checking the back of the card? Many of the card readers I see are on the customers' side of the counter, and I swipe it myself, often because I'll enter a pin. Also there are self-checkout kiosks with little or no supervision. I don't think that the lack of a signature line is the _biggest_ downside.

Your A/B explanation misses the point that the selection doesn't reveal the relationship, only the absolute value. Once you reveal both options, the selection reveals the absolute value and the position in the set.

Using your example, ignoring selection and envelopes and simplifying the goal of the answer: "Here's the letter B from a set of two consecutive letters. What's the other letter?"

Sell them! It's working for Apple.

As others said, this landing page doesn't tell me anything, let alone sell me on connecting my Dropbox. You can update it, but I still won't try it knowing that you have a habit of doing things with user data without full disclosure.

Are we all writing small jQuery scripts right into the HTML in a script tag? This post suggests that practice. I can see it being the faster option for just a 1-3 line script, what's the tipping point when we move it to an independent (minified) .js file? Is that just a readability issue? And why do I need all of jQuery to add/remove a class from one element?

It seems there's a conflict here: Either there's little JS and no need for jQuery, or a lot of JS and no sense in dropping it in the HTML.

Well I'm glad I finished a customization of the v2 carousel last night. Will this thing break if I update? I'm betting yes.

At first glance, this does seem a little lighter and more elegant for light projects than jQuery. I do see the chains could get long, but they might well match CSS selector chains I already wrote, so it's type-heavy but not brain-heavy. It's also such a light file that I might prefer it on a one-pager if the interactions are few and simple. That said, any jQuery plugin is lost with this option, so if have to decide against using any/all before I begin and if the possibility exists I'd probably err on the jQuery side.

Also CSS related, when doing margin/padding I use "TRouBLe" to remember:

    margin: (T R B L)

My god that sidebar on mobile is awful. It takes up 1/3 of the screen.

Nicely done. I'd style the :focus for the contact form, and flesh put the development page a bit.

Same thought here: For $7500 you can get something built without giving up equity or even going through an arbitrary vetting process. I've done this myself with offshore developers. It took 8 weeks to go from signing the agreement to deployment.

This is super similar to a (now defunct) SMS-based medication reminder application called GetMinders. I have confidence that this type of service could be useful, but I think taking medication is one (small) part of a larger problem of comprehensive medical treatment management. I'd really like to see someone tackle patient/doctor relationships in a project management type of tool. This would be better served as a piece of that larger platform.

Optimized version:

1. Ask a lot of people who fund questionable, unproven businesses what they'll pay for.

2. Promise to fulfill their requests.

3. Take their money.

4. Follow through on your promise like an honorable member of society. (optional)

Does writing a nested list in json cut down on the work much? I feel like a ul block is a small "repeater" (a bunch of li following the same pattern) and using this is a "6-of-1, half dozen of the other" scenario.

The concept sounds more useful for a table scenario, especially considering the table might be populated by json to begin with. It would make the HTML work easier and provide a easy connection between whatever feed I'm using and the parsed & rendered table.

If you (or anyone else) is building out new "blocks" that work with this project, I'd prefer to use it for parts of a site/page I'm likely to pull from a live/updated/for_each type section of code.

*ninja edit: How do you do inline code?

Adding to this, we are questioning the basement temperature in an urban environment. A city like Boston or New York has electrical and steam pipes under every street, surrounding these basements with a constant heat source.

Does this include using Dropbox for the local copy only? Still pushing to GitHub as usual, just using the Dripbox folder as the local directory.

> You are reading this on a computer.

False. I am reading this on my iPhone. On a toilet.

*Assumes "computer" = "desktop computer"

I agree with the "No one knows how to work with generalists" statement, and I have found myself scrambling to answer the "What exactly do you do?" question a few times. It feels like a small few appreciate the idea that I just like to build things and don't mind moving around to address issues in different "areas." Others expect to put me in a seat with a label on it and focus on whatever tasks require the person in that chair. I invariably get called something I'm brought on to the team and then switch gears unexpectedly. ("I didn't know you code.")

Your idea for pairing generalists is awesome, and I wonder if it's viable to do independently and "sell" two generalists as a team to recruiters/companies. Just like the art director and copywriter combo, two generalists sell themselves as a duo able to address any challenge from the server to sales.