I wasn't aware they had done anything. Do you have an article on the matter?
1,214 karma · joined November 6, 2008
I'm going to wait and see how the MBP line turns out, but I'm nearly at the point where I'm ready to jump ship and just deal with the pain of Linux.
I'd argue that though this is an avenue your listeners MAY use, it's not one the author ought to encourage. It's far more valuable to try and drive traffic to a site you own and control.
Here are some boring choices we made that paid dividends:
1. Postgres. It does what it does, it's stable, it's reliable, and continues to improve as time goes on. 2. Ember. It's by far the most stable front end framework going. It's made our job easy in uncountable numbers of ways. 3. PostCSS. Write plain CSS, use modern features, remove plugins as browser support grows.
A few years ago I'd have said Rails was a boring technology we chose too. These days I'd say it's a bit of a thorn. It's clear that some of the magical choices made make long term maintainability challenging, as are some of the performance characteristics. A few of the libraries used by the community have bitten us hard too insofar that they're either a maintenance nightmare, poorly maintained, or exceptionally difficult to migrate away from (e.g. CanCanCan, Active Model Serializers).
These days I'm playing with Elixir, which is also boring but allows you to do exciting things. I especially appreciate ExUnit having come from the RSpec world — assert, refute, end of story.
The web is one of the most open platforms that has ever existed — period. Since the dawn of the smart phone the web developer has heard the following request: "I need a native app because push messages!". Execs want them, users want them. They literally bang down your door asking for the damn things. Allowing the browser to handle push messages means you can keep your app on this amazing open platform instead of share cropping in some app store.
Would it be correct to assume that the majority of your time socializing is at work?
I'm at a remote-only company now, and have been so for seven years. I've found the key is that I have certain unconditional social activities I do after work. Without them I tend to go a bit squirrely and cranky. At work we also make a point to spend the first 5-10 minutes of longer meetings just hanging out, and get together in person at least twice a year.
Not at all. I think that some folks just don't work well in such circumstances. A close friend of mine was much like you: he craved the social environment, and the immediate collaboration with peers. Personally, I'm the opposite. I hate drive-bys, I crave the flexibility to work when I want and how I want, and the social interactions offer no real value to me.
I think it's great that you know how you best work. It's a key to happiness.
> If developers are remote, you will find that your code-base becomes the same. That critical FooBarAdapter becomes something that only Naimh can work on because without co-location if another developer is stuck on it, rather than grabbing her for a "Can you look at this?" over the shoulder, it gets slung over the fence in an issue or pull request.
That's just patently false. Not only can this happen in co-located work environments, but is often symptomatic of a poorly functioning team rather than how they're located on the planet.
I'm having a really hard time understanding this statement. Does the author mean with respect to how updates are handled? It clearly cannot mean in terms of sheer number of installs, Android is clearly _leagues_ ahead of iOS in that regard.
The point of a broad set of utility classes is to have predefined and discrete classes that map to conventions your application uses. Here's a few examples from an app I use:
.u-colorPrimary { font-color: var(--utils-css-c-primary) !important;; }
.u-textSmall { font-size: 0.75rem; }
Each of these are a "standard" that we use throughout the app. There are NO one-offs. These can then be composed into "component" classes (e.g. .Button, or .TextInput).
The benefit is mostly threefold:
* Maintainability is great. No hunting throughout the templates when you want to change the primary colour. Just update the .u-colorPrimary class, or its underlying variable. * Our developers can look at a design and mostly do it themselves. No need for a CSS pro to come in. * We can package these into a node module and share them across our apps.
You're right: this is laziness. I don't like to repeat myself, and I like consistency.
1) Housing. It's definitely not as bad as other "world class" cities, but it's bad enough that multiple parents are having to help their children buy homes.
2) Opportunity is too good. "Why not move?", you may ask. Well, there's only so many cities in Canada that are on the scale of Toronto for opportunities. Vancouver is one, but it's even more costly. Other cities just don't come close for job opportunities.
3) Our new Premier is a dip shit and actively ruining our province.
4) Access to outdoor amenities isn't so hot. There's some things, but you really have to drive 3-4 hours for the great stuff.
5) Transit is painfully underfunded. We need more of everything, and we need it 10 years ago.
6) City planning seems totally absent. We have 100k people moving here year over year. Entire new neighbourhoods are popping up almost over night, but there's zero planning in place. A prime example is Liberty Village. Getting in out is a nightmare. There are families growing up here without a new school to be found. There are no parks either.
I'm sure there's more. These are the first that come to mind.