robotpony

Around Vancouver our heat pump has performed adequately even down to -15C/5F. This may be related to it being a deep ground loop geothermal setup (vertical instead of horizontal), and the type of building (concrete). We do have a gas fireplace as backup, but have not needed it at the temperatures we see in this corner of the world.

I like the Serious Eats format, where they provide both a brief recipe and an optional backstory. Some of the research and reasoning is interesting for certain recipes (like pressure cooker French Onion soup), though when actually cooking the story makes finding the details a bit more work.

Wow, I had forgotten how retro-industrial those Atari language cartridges were. I also forgot how rich the language was, given the constraints. Great memories!

That's less bad than I thought the early pricing would be (and isn't far from the highest end sushi I've seen around the west coast here).

> "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." ~ Rob Pike

I used Markdown for recipes for more than a decade, where UL were ingredients, OL were steps, and you could use as many sets of both as needed. With some CSS and JS it worked pretty well, but wasn't super accessible for family members to add recipes to (but was great for me).

The price isn't even that bad, but it produces so much more packaging waste than cooking from scratch. We enjoyed the recipes, the price was good enough, but our recycling load doubled or more.

Previous gen didn't, so I doubt the new gen does.

I've had several things hosted on Dreamhost for almost 20 years now, and they have been pretty great.

That was my first thought.

A company grows into its funding, not what it needs to do (and they raised more than $300M over the years).

A promise is a promise ...

I should have said that there is no technical reason for delaying a streaming release, nor does it really affect the quality of the watching experience (assuming people have good streaming setups).

This is the crux of the issue: that cinema hasn't caught up with streaming services. There's no reason to force people to wait to stream a movie, i.e., they could show movies and stream simultaneously, maximizing consumer choice (rather than maximizing cinema profits).

A lot of guys are boring, especially for people who have studied and focused in their specialties for years and years. You have to find common ground, and that can become increasingly difficult unless your friends share parts of your core interests.

I work pretty hard to maintain some normal interests, enough that I can chat with pretty much anyone. I do find deeper relationships difficult though, as there are fewer people who share my real interests in my area (or even in my cohort of long term friends). Finding those people is difficult.

I've never found developers resisted reasonable unit tests, though teams may squabble about what _real_ unit tests are, or may have been burned by poor approaches to unit testing in the past. If you can find the cause of resistance, all teams I've worked with have been happy (even excited) to get better testing in place. It makes them more productive and more successful when done properly.

What I find more common is for the business to be unprepared to make lateral changes to a product. Even rational unit tests are a medium term investment. You need to spend time developing features customers don't see, and apply those tools for some time, to see quality differences. That can be difficult to justify in a number fairly normal business scenarios (low cashflow/reserves, high tech debt/regret, etc.).

To help offset the cost (and delayed benefits), I've always suggested phasing in unit test strategically. Pick a module or cross-section of the product that is suffering from bugs that customers see (i.e., affecting revenue) and add the minimum viable tests to that. Repeat as needed, and within months/years, you'll have coverage that fits the business needs well.

It's not exclusively a benefit, but it does have some powerful upsides:

* Less commute time and cost (I save 8-10 hours a week, plus a few hundred a month in parking, fuel, and insurance)

* More freedom and flexibility (not every gig offers this, but many do)

* A bunch of focus time

* Communications (oddly) are greatly normalized as everyone has the same handicap. I find a fully remote team easier to manage than a mixed one, as no one has an advantage over another (as happens when part of a team shares the same office).

On the other hand, you're maintaining your office space and much of your setup (internet, wifi, heating, desk, chairs). Again, some jobs offer some compensation here, but some of it will be on the employee to maintain.

You're also more isolated, and team culture takes a bit more work to create and maintain.

Personally, I value the option to work remote as a net gain. I love my home office, I save time and money on the commute, and I have more time to focus than in the office. I understand the company benefits too, as they pay less rent, own fewer fixtures, and get more of my time. But I still see it as a net win for me.

Most of these points all relate to having empathy for the developer and being kind, and focusing on the point of code reviews (which is to improve quality and reduce ongoing costs).

Example:

> Unhelpful behavior: overwhelming with an avalanche of comments

Code that isn't consistent to standards absolutely needs to be fixed. And while it's a lot of work to keep code up to standard, the author is correct that the nitpicking approach is unproductive.

A better approach is to review code like this, see that it falls short, and suggest realistic (and in turn kind) ways to improve things. Picking at each missed space is clearly counter productive, and there are more standard and helpful solutions.

Why not suggest adding:

- lint tools - requiring code meets standards - auto formatting tools

I don't think things like minutia fit in code reviews either, but the small stuff does matter.

I feel the same about the other suggestions, they can be boiled down to: don't be an ass; be kind; be constructive. Just imagine that you're reviewing your own code from 5 years ago.

Clean French press, fresh / burr ground beans (12:1, so usually ~60g ground), temperature controlled H20 (96C), 4:30 minute brew.

""considered harmful" considered harmful" _considered harmful_

> merde(`partout`);

I've had a few servers (and previously shared hosting) at DH over the last 20 years. While they have had their fair share of major downtime, it has been on par with Rackspace, AWS, etc., who have all had day+ events in the last.

I have heard reports of some shared servers being worse than others, but generally I've only seen reasonable performance at a low price.

That said, I also use Digital Ocean, AWS, and Rackspace still for various projects. Really, they're all pretty great.

I'd like to see the actual distributions of foods (and micro/macros) in these studies along with the human stats (ages, activity levels). I suspect that the factors are for more multi-modal than the buckets of "low carb" and "high fat". Open source data here would allow for alternative views on the data, and likely better learning overall.

Also tried to apply. At least 60 years worth of experience, if you consider accelerated rate of practice. Disappointed in 500. Thhhbbbttt.

DSLs can be great abstractions and interfaces, in that they can provide a way to state program knowledge in a form that non-programmers may be able to work with more easily.

One example that stuck with me early was the Quake (and Doom) shader files, as well as the other game resource constructs from those old WAD-based games. The shader syntax wasn't much more than a rough wrapper on the program's `struct`s, but it allowed the graphic artists to twiddle with the resources manually (and later made a great program interface for the level editors).

Quake map files were [pretty neat too](https://quakewiki.org/wiki/Quake_Map_Format), compiling down to playable levels as BSPs (binary space partitioning files).

XML (specific to document interchange), HTML (specific to hypertext interchange), and CSS (specific to DOM settings) were all DSLs that came about over the course of browser evolution. They offered ways to define content and configuration in a way that was both easy to understand and somewhat isolated from the underlying source code.

I've developed several DSLs in various systems I've worked in. Mostly you're pushing stuff out of the source code that doesn't belong there: configuration, repeated definitions, and things that may change from installation to installation. One of the abstractions we built was a series of custom state machine scripting languages that mapped to serial and TCP/IP protocols in a way that reduced boilerplate, and made the guts of implementing specific communications scenarios easier. The amount of time spent in developing a DSL was generally many times smaller than the gain in flexibility, transparency, and exposure to who could interact with customizing the system.

Side projects and life-long learning are the only way to stay relevant.

Stop feeling guilty for not finishing side projects (only finish the good ones).

Adapt not just your skills, but your learning techniques (you're not in college any more, and the learning landscape is evolving quickly).

Don't be overly loyal to your company, at least more than is rational (their loyalty to you is limited to shareholder return and their basic humanity). This isn't to say you should bail early (as you won't learn or ship anything real), but value your own career over the number of years you stay with one company.

Look ahead regularly: where do you want to be in 5 years? It takes 5 years to get somewhere (like front-end, back-end, kernel dev, UI designer, etc.). As this question EVERY WEEK, and do something about it.

Make good habits: your habits are your learning and productivity, this includes the wetware (i.e., you).

I tell my teams this regularly: you'll hate all legacy code you work with, especially your own. This means, in essence, that you always hate your past self.

Pushing that hate for legacy code to your own self is important, as it as a good motivation to improve (for us narcissists at least).

No need to replace your console either, they tend to last for ages. We still play our Game Cube and N64 regularly (as well as Wii/Wii U), so total lifetime is pretty huge. It's enjoyable to play these old systems, where a video card isn't really that interesting 5 years later.

Vancouver had more like 12 murders last year (http://vancouver.ca/police/Planning/2016YED.pdf).

LemonStand | Canada (Vancouver) | Full-time Full Stack | Onsite | Remote

This is position is open to remote team members living within Canada, or for Vancouver folks to work (mostly) in our lovely downtown office.

We're looking for a skilled Full Stack Developer to join and lead our front end dev team. At LemonStand we help web designers and developers create some of the best online stores for fast growing brands. We've released many exciting new features and tech, and want you to help us build more.

You will be working with the founder and CEO to understand how our customers use LemonStand to build great online retail businesses, translating that into product features and priorities. You'll also be working with the CTO to develop these user stories into productive experiences and technical principles, applying them to the product on a weekly basis.

At LemonStand we get excited about our customer's success, we obsess over the stories of the people who use our software, we know their business challenges and workflow and we want you to help us build software that'll make them hugely successful.

You would be working using a number of standard tools and driving direction for the front end stacks.

Tell us about yourself at [jobs] at [lemonstand.com], or learn more by visiting: https://lemonstand.com/careers

I have two setups: one large single monitor, and one dual setup.

I had always thought that the multi setup was better, but have found over the years that it's only better at certain things (for me). I've found the single monitor setup better for tasks that need focus. Full screen apps (or nicely tiled sets of apps) for single task work well on one larger monitor. This fits writing, initial coding of modules, visual design, and reading dense material.

The multi monitor setup is great for tasks that require many views, especially collaboration, research, and projects with many reference materials.

I would love a desk that let me switch between the two, or windowing software that made it trivial to get to a focus mode that disabled the extra monitors when I needed extra attention. Those times where focus is important, I find the extra monitors, light, and visual noise distracting more than seems logical.