Next they should trim the keyboard, monitor, battery, touchpad, and everything else except the Apple logo, since that's really all that matters anyway. Then you'll be able to travel really light.
I am all for portability but there comes a point where you start trimming essential functions. I'm not saying every laptop needs to have a SCSI port, but ONE connector?! I thought Apple was bad before with two USB slots and mini-DP. My Thinkpad Yoga, which I bought specifically for portability, manages to have 2 USB connectors, HDMI, built-in SD card reader, and other useful peripherals onboard, and yes, I do actually use these.
I think MacBooks are cool but I always find myself unable to use them for serious work. If I was a casual computer user that just needed to update Facebook once in a while, they'd probably be fine, but every time I've tried something more serious than that with one, I've ended up on a non-Apple product because why torture myself over fashion?
I suppose it depends on how you define "essential", or perhaps "serious work".
Granted, most of what I do with my MBP is modern full-stack stuff, which I gather doesn't qualify as "serious" even if it does make me a good living. But I don't see how the type and number of ports on my laptop would make much difference if I were, say, writing Linux kernel modules for hardware nobody uses, or building a window manager in Haskell, or whatever the current definition of "serious" is among those who put so much weight on the term. I need to plug in a real keyboard; all else is commentary. (And who does embedded away from home, anyway? There's too much you need besides the computer, unless you're targeting an emulator, in which case what need have you of physical ports?)
But, hey, it's always easier to feel superior than it is to see the other guy's point of view.
I have a wireless mouse that works via a USB dongle, and I use a USB headset for my Skype calls with my business team. I also charge my cellphone from a USB port, especially when travelling, as it's far more convenient to have one plug adaptor and my Macbook Pro power supply than carrying a plug adaptor and a multi-box everywhere.
At the moment, the two USB ports I have on my MBP are pretty much bare minimum but every now and then I find myself juggling peripherals.
You might consider the same cheat I use for charging, which is to keep a small but reasonably capacious USB battery [1] in my bag, and top it up via USB whenever I happen to have a port free. Since it's specified to fully charge an iPad twice, it can charge my phone several times before running flat, and a fully powered USB port can charge the battery itself in a matter of a few hours -- an overnight charge is ample. (And, hey, the only thing I ever plug in my phone for anyway is power, so it's not like I'm losing anything by not plugging into a port on my laptop.)
Another trick worth considering is, instead of using a USB headset, instead to use one which connects via the headphone jack proper. Mine is a Sennheiser HD558 with an aftermarket cable incorporating an Apple-style mic/remote module, but you don't have to get that elaborate, especially since the HD558 isn't designed to travel and does not do so well; for simple VoIP purposes, anything halfway decent will do, and serve the purpose of freeing up a USB port for things that a headphone jack can't do.
Why should one go to all this trouble just so he can use a Mac? There are many decent competitors out there that don't require these types of hacks (and for the record, I carry two USB batteries in my bag since there are occasions when I'm in the field for extended periods of time (24 hours+), but I certainly wouldn't be charitable to the idea of draining that backup power because Apple thought I needed to save 2mm of vertical space more than I needed the ability to transfer battery power from my laptop to my phone). That's the gist of the thing here. Apple people take using Apple products seriously and will go to lengths to make it work. Other people take their work seriously and will use the tool that best suits their needs. It's hard for me to imagine a MacBook ever best suiting the needs of a user that's more advanced than the casual Facebook browser just because so many sacrifices are made for aesthetics, and honestly even that market is a dubious target for the MacBook since the emergence of the tablet (for lighter casual users) and the ultrabook (for heavier casual users).
Do we care more about having the sexiest laptop in the airport or getting more productive time in? That's the dilemma one goes through when choosing PC v. Mac.
Well, I'm not going to all that trouble specifically to use a Mac; both the headset and the USB battery long predate the MBP. (And USB headsets have never made much sense to me in the first place, regardless of the machine with which they're used.) These are just the expedients I currently use, of the sort which I've found all portable machines to require.
The sine qua non of a computer's usefulness to me is its ability to support Emacs. While my experience has been that, all else equal, any portable machine is inferior for this purpose to any desktop, I have yet to find a better portable Emacs machine than the 15" rMBP. When I do find one, I'll use it instead.
If your "all Apple users are fashion-obsessed lightweights" proposition is susceptible to the white raven's disproof, this should amply suffice. (When was the last time you ran across an Emacs user who was either "fashion-obsessed" or "lightweight"?) But I suspect you'll prefer to explain away a white raven, than to reconsider your apparent confusion of reality with an "I'm a Mac, I'm a PC" ad.
When I sit down to work on a laptop, unless I'm just stopping to check something for a couple of minutes, I usually want to plug in at least my phone (since publicly-available WiFi is not really a thing, often I have to USB tether to get usable connectivity (I could wifi tether if I had to, but this kills the phone's battery)), mouse, headphones, and AC adapter. I'll pretty frequently want to use an external storage device like an SD card or USB hard disk and if I'm in a real office, I'll usually want to plug in to the physical network (even non-Apple portables don't include this port usually anymore, so that's another USB port occupied) and use an external keyboard.
That's just me. A few of those things could be transferred to wireless peripherals, but not all of them, and wireless peripherals usually suck pretty bad. I have a Bluetooth headset that I try to use in the field occasionally and it's a nightmare switching between A2DP and telephony modes. I could switch to a wireless mouse, but then that's batteries and many of these take up a USB port anyway with a proprietary dongle. I don't usually carry a full keyboard around with me so I just gotta use what they have in the office, which again, even if it's wireless, often occupies a USB port.
To me, this is serious. I don't think I'm doing anything super special; I'm definitely not writing custom firmware for esoteric embedded devices from Starbucks or anything like that. Just your everyday developer and sysadmin.
Now, if I put a lot of effort into it and decided I was going to live on a MBP and therefore needed to keep my usage restrained to one or two USB ports max, I may be able to come up with an arrangement that works, but it's by no means the default; I most recently tried to live off a MBP for 5 months in the first half of 2013, and it didn't work out (the lack of ports was a constant annoyance, but not the impetus behind the change). I swapped it for a Thinkpad and was much happier. I find this happens to me every time I try to live off an MBP. The most successful run I had was 2006-2008 where an MBP was my sole laptop and I did a lot of remote work, but it was not really pleasant and I had a desktop that I used to supplement.
To be clear, I have bought 3 Apple laptops over the years of my own free will and used a few more that were owned by employers. It's not that I hate them (in fact I continue to be astonished by Retina displays, which I was sure was just going to be hype before I saw it in person, and wish PC makers would catch up), but I just don't think they're good workhorse machines for people who do real work. I think they're mostly a fashion thing that people force themselves to live with. I'd love to have one around the house as a casual computing machine, but it's hard to justify dropping $2k for the setup, when again, there is real work that would be better served by the same investment going to actually useful equipment or to labor.
I just don't really see a reason to force myself to heed Apple's insistence that while I think I may want more than two ports, I really don't. Even the way I use Apple hardware usually pisses off Mac devotees -- back in 2006 I made some permanent enemies out of a few acquaintances that were stunned I would be voluntarily using Fedora on a MacBook Pro. They kept repeating that they'd totally understand if it was a PC, but if I had to use Linux on a Mac, I was most likely just a retard who couldn't grasp the beauty gifted to earth by Humanity's Eminent Genius Steve Jobs. They continued this hostility every other time I saw them. Pretty bizarre.
When I sit down to work on a laptop, I want to open my laptop and start working. I don't even think about a charger until three or four hours have gone by. Your farrago of impedimenta is alien to me, but no doubt if I had something like it, the MBP's relative paucity of ports would annoy me, too.
I'm not so sure. I find most such persons will put some money into a phone or tablet, but if they have a laptop, they usually buy a cheap one from Wal-Mart for under $300.
As far as I can tell, the market for Apple's laptops are normal hipsters, hipster devs that can't stop talking about how you can build a blog in only two hours with Ruby on Rails, video and photo editors clinging to the meme from the 80s that editing software is somehow superior on a Mac, and college students that don't want the embarrassment of using an "old person's computer".
A stall warning occurs when the angle of attack (angle between the wing and the airflow) is too high to maintain lift. There is a separate instrument for detecting this (which can also be disabled by ice build up, but appeared to be working here). Low airspeed is not the only condition for a stall - it can happen even at high speed!
Or don't use branches at all. Develop on trunk/master with continuous integration. It reduces work-in-progress, exposes conflicts sooner and has a host of other knock-on benefits.
To 'CI' [per se] I say "yes, of course." It's a best practice. But it is not a substitute for branching! I want to choose when I'm exposed to conflicts. "Sooner" is usually -- but not always -- "better". Summary: strong disagreement on this radical approach.
I don't consider not-branching to be a radical approach. If you are using branches you really aren't doing CI, because you aren't integrating continuously.
> If you are using branches you really aren't doing CI, because you aren't integrating continuously.
Perhaps this is just a terminology issue, but I strongly disagree with this. You can always merge/rebase the latest version of master into your feature branch.
That will integrate other people's changes into your branch. But until you also merge your branch into master (and/or all other branches), you are not integrating your changes.
So there are projects where I don't branch: ones where I am the only committer, and there are no features. For example, my puppet manifests for all the servers I manage. It either works, or I roll it back.
However, feature branches are just multi-stage commits. Sure you can invest hours of your life setting up CI, then writing code, not testing it locally before pushing it to master, getting an obscure error from the test/deploy process, fixing it again, pushing again, getting another error, etc. But you probably want to, you know, ship the product.
Having said that, if your workflow actually resulted in you writing better code faster and you ended up shipping earlier and making more money, I'd love to read about it.
"Sure you can invest hours of your life setting up CI, then writing code, not testing it locally[...]"
Maybe I've misunderstood, but why aren't you testing it locally? With trunk based development you make your changes, run a local build and push if it passes. Everyone (including any CI servers) runs the same build process.
The trick is that you have to be able to push to master without breaking it, which is scary to many developers and usually requires a shift in thinking. How do I do large refactorings? (you don't - do many small refactorings instead). How do I add a half-finished feature? (break the feature into many smaller features, use feature toggles, etc.)
Of course. And this relies on your CI system having 100% unit and system test coverage, including testing external API's, CSS bugs, browser compatibility, etc. Are you certain that your system does that? More importantly, are you certain that investing the time into testing that your checkout button is not covered up by some random element due to a missing ";" character in your CSS file or a missing 0 in the width percentage value will eventually pay off? It should be scary to push to master if you hold master to be deployable at all times. Unit/system testing or not, you will never have guaranteed test coverage, and even if you try to get to it, you will spend infinitely more time doing that, than doing a reasonable amount of unit/system automated testing + good human QA.
That's really a function of your QA process, not anything specific to branching strategies. If you can automate everything such that continuous delivery (or even deployment) is possible - great. If not, deliver at whatever pace your QA allows (and strive to increase that pace). Trunk based development does not imply a diminished QA process.
Yes, there is always going to be a feedback delay between you making a change and the full impact of that change being known (even if your feature is bug free, will the customer want to use it?), but we should be bringing that feedback forward by moving changes through the pipeline as early as possible. Feature branching delays feedback, which is why I reject it.
Both Google and Facebook use trunk-based development. If Google can get away with a single trunk and 15,000 or so committers, chances are your organization can too.
The reason for trunk-based development over feature branches is that the time required to integrate a patch usually increases proportional to the square of the time since last integration. With trunk-based development, most commits reflect about 1-2 days worth of work, and they go in with minimal conflicts. Branches (and patches that sit idle for a month or two) often take forever to integrate, because as you are trying to update your code to the new master, the master is itself changing. At some point, the process doesn't converge, and you can spend forever trying to update a branch.
This is my preferred method too. But a lot of developers struggle with the discipline of small, discrete, incremental changes, plus the dependence on solid testing skills. It also requires a culture that can support it. No blame, in particular.
However, if you have a team that is comfortable working this way -- and is only occasionally breaking things; it happens -- then it is a wonderfully creative, frictionless, and flexible way to develop.
No, people will always kill other people, that is the unfortunate truth of human nature. That doesn't mean there aren't multiple problems here, and each one with multiple solutions.
Our lawmakers know just as well as we do, that more laws won't fix events like these, but better messaging ("See something say something"), better trained police officers, etc.. these are things that are controllable, changeable, and have a hugely positive impact on preventing horrible things like this from happening.
"See something say something" is still far too late in the process. As a society we need to do a better job of preventing people from being abused, neglected, and marginalized.
Absolutely old chap. For some reason lots of people seem to think that I'm American and complain that my representation of British people is inaccurate. I think they miss the joke.
One saving grace is the High Line. I think it works well to serve public WiFi in places where tourists are going to be- they're likely not using their (expensive, international) data connections but need to get access to info.
WiFi like this already exists in Union Square and Times Square.
