mcmatterson

I'm facing the same dilemma with a hardware project of mine (http://tooner-test.moshozen.com). In the past month alone, I've been stuck on several things (public name, dealing with constant ID creep, finding a mill that can resaw, among others). Though they're contradictory, it seems that half of the roadblocks get solved through putting them off (and usually thinking of a better solution, or a workaround), and half get solved by #JFDI.

'Shipping' means something much different for hardware projects of course, but nonetheless I think the advice to ship on day one is really foundational. I've always been fond of the idea that 'if something hurts, you need to do it more often'. Make the game about iterating and not shipping.

That's 40gbps of voluntary (technically settlement free, but not in the usual meaning of the term) peering, not paid transit. Paid transit numbers are several orders of magnitude higher, and total traffic numbers are unknown.

This is a big deal, actually. It's a EULA for cars.

https://github.com/NextThingCo/CHIP_Pro-Hardware/blob/master... suggests it's GadgetOS, which appears to be a New Thing. Anyone have any info on it?

I can't seem to find any mention of the specific OS these use. Anyone?

I just do it in Sketch. For me, any evolutionary insights are secondary to shipping, so I'd rather stay on the golden path of tooling than adapt the flow just to see changes. However, it's generally pretty easy to simply zoom out and see your evolution just by looking at multiple artboards at the same time (the changes I'm interested in are more about feel and aesthetics, so I don't really need any pixel level onion-skinnng or anything to compare revisions).

FWIW though, Github's image diff is quite useful in this regard. They have a number of useful comparison interfaces for image files that may fit your needs.

I started doing something similar with the small amount of UI work I do, modeled after [1] (a great watch, BTW). For example, my flow for app icons is like so:

1. Spend some tiny amount of time building the simplest thing that represents your idea on an artboard. The focus here is to function as a first step, not to strive for perfection.

2. Identify one thing to change (shapes, colours, font, etc).

3. Duplicate the whole artboard, and tweak that one thing on the copy.

4. GOTO 2. Keep looking back at previous artboards and don't be afraid to revert if you notice that you've been off course for the past few iterations. Never delete an artboard, just go back and fork.

5. Stop when there's nothing immediately obvious to tweak.

It's a simple workflow that produces much better results than endlessly tweaking a single artboard, and you can see your evolution over time, so it's easier to identify the things that work / don't work to improve your skills the next time around.

[1] https://vimeo.com/113751583

I did a bit of a dive on it a while back - it works via peertalk (https://github.com/rsms/peertalk), which in turn works by connecting to local sockets provided by `usbmuxd`.

I always wondered about where that promise went. Do you have a source for your statement?

As with anything they ever covered, The Secret Life of Machines has a superb episode on the vacuum cleaner:

https://www.youtube.com/watch?v=LS_WcIAPSzU

Truly one of the best television shows of all time.

Those photos are nothing compared to some of the firsthand videos:

https://www.youtube.com/results?search_query=fort+mcmurray++...

It's honestly like something straight out of an apocalypse movie. Horrifying.

A few years ago I dove into the idea of trying to make a C only iOS app (well actually, it was a quick exploration of how hard it would be to build your own UI kit without using UIKit). The dive bottomed out pretty quickly, as I couldn't figure out a way to access windows without resorting to UIWindow methods, and `UIGraphicsGetCurrentContext()` acted super wonky calling it without 'proper' bootstrapping around it. I was expecting more, given the usual layered approach that Apple takes with their system libraries.

The snow really isn't a factor at all anymore. If you live right (near the subway & in a neighbourhood where you can get everything you may need in a pinch locally) you don't even notice it. I can probably count on one hand the number of days that I've been impacted by snow in the past few years.

In terms of NIMBYism, I don't think there's much more here than in similar cities. To my eye it's more about people being indifferent to the effects of gentrification on marginal populations, and a growing danger of homogeneity in many 'hoods.

It's telling that Toronto isn't on that list. It's taken me a decade of living here to really understand what makes this place tick, and one thing that's become clear is that a near universal friendliness to newcomers in both word and deed is a huge part of Toronto's identity. I've said it before in many conversations on the topic, but I think that this pervasive openness is going to do nothing but help Toronto's place on the world stage

A close friend of mine was on a previous Hi-SEAS, and I can say that this was also one of the first questions we asked of them upon their return to Earth. According to my friend (who I'm not identifying out of respect for their privacy), the, uh, 'interpersonal relations' are in fact both manifest and juicy, and are a very substantial part of what they cover during the extensive surveys and debriefs that take place during and after the mission. It's a big part of what they're studying, even if they don't talk about it publicly.

Essentially, our daughter is much more likely to partake in an activity (be it eating her veggies or anything else) if she feels like it was her idea to do so. I'm not entirely sure if it's the choice aspect, or the preparation aspect (in other words, that she knows in advance what to expect).

We're careful to emphasize the sanctity of personal choice wherever we can, and to encourage her to make her own decisions based on an evaluation of her options (really, we're fine with her picking any of the menu options we give her; if she picks a gross combination it's hers to eat, not ours). The important thing seems to be that once she makes a decision, she becomes invested in it and is much more likely to see it through.

I probably shouldn't discount the preparation aspect, however. She eats much more of her lunch when she helps to prepare it (and thus knows what to expect when she opens it at school). Similarly, we have a countdown for bed ('bedtime in t-5 minutes! Bedtime in t-2 minutes!') that makes the transition to nighttime more or less painless.

This is also great parenting advice. Give your kid the feeling of having chosen to eat their vegetables, and they'll devour an entire plate of them.

Unnamed Apache version, but serving HTTP 1.1.

Also a parent of a 4yo, agreed 100%. I notice a difference even if I don't get woken up at night (which thankfully is a rarity). I think it's mostly a matter of how I get woken up in the morning (she's basically our alarm clock), even though I get up at roughly the same time when she's not around.

I've also noticed that the rare nights when she's completely out of our care (at her grandparents), my quality of sleep is even better still. I wonder if there isn't some sort of psychological stress that affects sleep quality when there's a kid in the next room who's your responsibility.

It's Ridley Scott doing a Mars shipwreck movie. I hope the humour is at a minimum.

I remember a number of years ago I was setting up a shared access shell machine, and came across the idea of piping pine directly into the IMAP server via domain sockets, in an on-demand fashion. It was a revelatory experience for me in the Unix way, seeing how interchangeable TCP, domain sockets, and files are in general. Even this article's example is quite a bit more abstracted than the simplest case in ruby (which itself is quite a bit more abstracted than what you can do with building blocks like `nc` and `echo`).

Being able to see that 'socket / file duality' is one the best observational powers a network-facing developer can have. It's also one of the biggest worries I have about HTTP 2.0.

We went through this usage based billing (UBB, aka capacity based billing (CBB)) thing here in Canada a couple of years back, where the incumbent carriers (DSL and cable) somewhat successfully lobbied the CRTC to set wholesale tariffs based on a mix of generally lower access fees (paid per subscriber, specifying a certain connection speed but no actual traffic), and interconnect fees (covering a certain interconnect speed between the incumbent's network and the third party ISP's backhaul). The net effect of the model is that a third party ISP's variable costs are essentially the cost of their interconnect with the incumbent, and are dominated by their burst needs during peak usage times. As a consequence, there are a number of business models which this lends itself to (in terms of incentivizing users to shift usage to off-peak times) in addition to straight download cap vs. unlimited offerings. For example, some ISPs (like Teksavvy, for example) offer unlimited plans with a reduction in speed during peak hours.

There was a LOT of debate on the subject on places like dslreports when this was in front of the CRTC. The general consensus seemed to be that UBB in principle is a good thing (it allows for more flexibility in third party ISP business models, and roughly aligns costs with income for the incumbent) although the particular tariff prices put forth by the incumbents were inflated and suspect.

As a real-world benchmark, my third party provider (start.ca) offers a 30/5 cable plan with 200GB of usage for $45 CAD (roughly $40 USD) per month. Going to an unlimited plan adds an extra $15 CAD to that, with the risk for overages being borne by the ISP.

Of course, the incumbents' retail offerings are universally terrible (their caps are laughably small, and their prices higher than any third party provider). Because of the lack of separation between their retail and wholesale operations, they're able to offer (presumably loss leader) promotions that third party providers simply can't, and have the benefit of being able to structure their tariff offerings to screw third party providers wherever possible. So that part of the regulatory environment sucks.

Overall though it feels like a decent model (although the actual tariff prices are quite out of line, particularly for interconnect fees). $60 CAD a month for unlimited 30/5 is a fair price in my mind, and if my needs ever change there are enough third party provider with enough diverse business models that I'd likely find something that works for me.

I'm going to do a bit of shameless self-promotion for my CLI tool for ad-hoc deployments, hawk:

https://github.com/mtrudel/hawk

Using a bit of XML glue, it uses simple building blocks of xcodebuild, S3, and email to give you one command building and distribution of your app, all driven by a plaintext Hawkfile. I (and a few colleagues) have been using it for a couple of years now, and it's been a real boon. Would love feedback.

Exactly this. I'm holding off on Swift for as long as possible for many of the reasons that others have said better than I can (in a nutshell, it's got all of the bad parts of C++, with few of the good parts of ObjC).

The approach this article suggests would have been ideal; fix some of the warts of Objective C, but stay firmly rooted in its spirit. As things stand now, I'll be learning Swift out of necessity, not desire. And I'll be putting it off as long as possible in the somewhat selfish hope that it's a flop.

Building up a basement rec room stereo from a Heathkit kit is one of many electronics related memories I have of bonding with my dad. I was less than 10 years old, and I'm sure he did most of the work, but it certainly helped teach me -- as the article so wonderfully says -- that machines weren't magic, and that curiosity combined with a healthy dose of fearlessness was enough to understand just about anything. What a great thing these kits were.

We also have one of those signs, from when a good friend lived next door to Dr. Bob's workshop (he being the purveyor of those signs). He's an incredible (and incredibly oddball) guy, and a visit to his workshop / junkyard is a great example of the part of New Orleans that most visitors never see.

There's a pretty massive bump in IPv6 usage on weekends. I'm assuming this is likely due to residential / mobile IPv6 adoption being higher than commercial adoption?

Agreed. In many respects, what I really want is a 40"+ monitor. An effective power save mode could obviate the need for HDMI-CEC, and I'm sure I could solve the outboard OTA tuner problem easily enough.

Amen to this. I did quite a bit of digging last year to find a dumb TV that did the basics (high panel quality, input switching, HDMI-CEC) well and otherwise just stayed out of the way, and I gave up. A couple of companies have a 'commercial' line that gets close to this, but they were priced totally out of line with their consumer counterparts. Similarly, many TVs have a 'hotel mode' that comes close, but it's invariably undocumented and can easily lead to bricking your TV. It's a wasteland of a marketplace right now, and only getting worse.

I always took his statement to mean that if something is essential to your business, you should think very carefully about the risks inherent in outsourcing it. The two major exceptions to this are

1. Things which aren't essential to your business. (e.g.: things that could be replaced by nothing (even if just temporarily))

2. Things which meet the definition of a commodity, in the formal 'fungible goods' sense of the word.

Many .?aaS offerings fail both of these tests in that they're an essential component of a service, and also fail the commodity test in that there is qualitative differentiation between offerings. The features of EC2 (used to their fullest) are wildly different than those of Rackspace, and the two are only really fungible with one another across a small subset of their feature sets.

Examples of offerings that pass this commodity test include:

- Most mailers (sendgrid, mailgun, postmark, &c) when used simply. Switching from one backend to another isn't a huge endeavour, as they are all cut from conceptually similar cloth.

- VPS offerings when used simply (notice a pattern here?). A basic Ubuntu box in the cloud is a basic Ubuntu box in the cloud.

In contrast, Stackmob, Parse, et al. all fail this commodity test hard. Switching costs are very high (especially with Stackmob, whose iOS SDK bleeds anti-patterns all over your app), data migration is a nightmare, and major architectural assumptions can vanish in an instant

Part of the bargain of leaning on non-commoditized offerings to back essential services is accepting the risk that they may one day leave you in the lurch. In the metaphor of technical debt, outsourced services are extending you credit to finance your technical debt. Having one of your outsourced dependencies close up shop is really just them calling in their debts.

Of course, there's no right answer. I agree completely that the point is moot unless you ship; the GP wasn't really intended to be imperative; it was meant (or at least it was always how I understood it) as more as a heuristic to assess the risk associated with outsourcing a core dependency that can't be easily hedged.