Simon Wilson recently explained that you can get information on the original and current capacity of your battery using the following command:
ioreg -w0 -l | grep Capacity
This works great on my machine, but just thought I'd mention that for those afraid of the command line, as I've previously mentioned, there's a great little utility called CoconutBattery which provides a GUI interface to all this. Try it, you might like it.
From MacWorld:
Huge newspaper makes Mac switch move - Mac - Macworld UK:
One of Europe's largest newspaper publishers, Axel Springer AG, has announced plans to migrate its 10,000 employees and 150 newspapers in 30 countries to the Mac
Speaking in a video message that's now available through YouTube, company CEO Mathias Döpfner notes the following four reasons for the shift:
- 'Most of the company’s layout work was already being done on Macs
- 'Macs are more user friendly than other computers
- 'Apple creates the most elegant computers
- 'Macs are cheaper to buy and easier to maintain than they were in the past.'
Could this be the start of a trend? I'm not expecting an avalanche of such announcements in the near future, but the world is changing. Microsoft seem to be suffering from horrendous PR problems at the moment, with people (regardless of the reality of the situation) starting to view them as dazed and confused. I saw a magazine cover the other day which posed (if I remember correctly) the question: "The end for Microsoft?".
The $64000 question for me is "are Apple really any better than Microsoft?" I think the jury is still out on that one...
Why is it that all laptop batteries eventually die?
Whenever I charge my MacBook Pro completely, the battery meter stops at 98%, and the battery says it's charged. I'd like to think this just means that I get 2% less charge than I used to, but the reality is far less appealing. When I unplug the juice, my laptop informs me I've got 1:33 to live. I used to get at least 2:30.
I know it's a reality that laptop batteries behave like this, and I'm aware that nothing short of a breakthrough in chemistry is likely to change this, but what I would like to see is some kind of transparency about the state of the battery - an advanced battery meter if you like. Something that shows the theoretical battery capacity, the charge attained last time it was full and it's current level. The meter could also show the number of 'charge' cycles the battery has been through to provide a view of the likely useful life of the battery.
I guess it would look a little like this:
Thankfully, someone's gone to the trouble of doing exactly that. CoconutBattery provides all of the above information at a glance, allowing you to understand exactly the position you're in. Which in my case is that I'm the proud owner of one of the oldest MacBook Pro's on the market (29 months? Has it really been that long?), and its battery is getting a bit weary. Perhaps it's time to buy a new one...
Dear Santa, please find attached a video of what I'd like for Christmas this year. I know at first glance it might look a little dangerous, but it'd be a hell of ride...
From BBC News: Rocketman flies in the skies.
I'm sat on a train at the moment, from Norwich to Ipswich. This train will take 39 minutes to reach its destination. It'll then take me 7.5 minutes to walk to the office, 1.3 minutes to make a coffee. I'll be ready to work at 08:17:48. Obviously, I'll stop to take a sip of coffee at 08:17:57, 08:18:20 & 08:18:50, and a large, cup emptying slurp at 08:19:20. Other than that though, it'll be working straight through 'till 17:30:00. I will not get peckish and stop to raid the snack machine. There will be no interruptions. Nobody will, at short notice, book a meeting or pitch up at my desk for an impromptu chat about the current status of Project X or Initiative Y. My fiancé will not send me an SMS asking me to pick up a bottle of wine on the way home, and absolutely no recruitment consultants will call. All my days are like this. I never have a bad day, never fail to get my head around the task at hand first time, never struggle to think where to start. All my tasks are predictable, have well defined goals and require no assistance from anybody who might be having a bad day. Of course, in this environment, I deliver what I said would, when I said I would with 100% certainty, every time.
Of course, I'm dreaming.
The reality is that nothing about the average day of the average employee is in any way precise. My train might take 39 minutes, or it might take 41, or if I'm lucky and there's a northerly wind, it might take 38 minutes and 59 seconds. My walk will be marred by traffic lights, and I (shock) will have bad days. If I were to use the fingers of every occupant of this rush hour train to count the number of times I've been asked by a project manager over the last 10 years "How long will this project take? How much will it cost?", I'd probably have no more than two fingers left to type the remainder of this post.
The trouble is, you see, I don't know.
Don't get me wrong, I can estimate things as well as the next guy - it's just counting widgets at the end of the day, but I know I'll be wrong. Of course, project managers are reasonable people, they say things like "Well, we have to be 100% confident in this estimate, so we'll add 10% contingency to your total, ok?" No. Not OK. The issue here isn't that I under-estimate routinely (although that might well be an issue), it's that adding ten percent will not make any estimate 100% confident, and nor will adding thirty, one hundred or even three hundred percent, regardless of how good an estimator I am.
Anyone who remembers the whale and bowl of petunias from Douglas Adams' Hitch-hikers Guide to the Galaxy will remember that according to Adams, the sudden appearance of flora and fauna in deep space is unlikely, but none the less has a real finite probability. Perhaps somewhat shockingly, this sort of thing is a reasonably well accepted side effect of quantum mechanics; this could happen at any time in any place. You could be just tucking into a medium (sorry, Grandé) cappuccino at your local Starbucks when something, anything, appears. House, car, cat, dog, frog, you name it. Now, just to stop you panicking over your caffeinated beverages, the chances of this happening are infinitesimally small, but it serves to illustrate the point that you never know what might get in the way of your project.
So, finally, to the point of my post. I think it's time estimating grew up a bit, and stopped pretending that it knew all the answers. What's needed is a way of estimating the cost and duration of a project that softens the boundaries a bit, and gives a truer picture not of how long a project will take, but how long it might take. Imagine for a second that a programme manager knew that there was a 66% chance that the project would be in by Christmas, and a 88% chance it'd be in by June. He'd probably be much more likely to give the board a sensible message than if all he had was a vague message from you that it could conceivably be done before the turkey gets cold. Equally, those of us who sometimes work on fixed price contracts would have a much better way of assessing the risk of a given project, allowing us to reliably turn a profit while offering a good deal for the client.
It strikes me that there are two approaches that could be taken to this:
I've thought long and hard about this over the last few years, and frankly the former option is beyond the capability of my AS-level statistics. Even if it wasn't though, I'd be recommending the latter, and here's why: It's intuitive. What you're doing is running the project over and over again, and seeing how long it takes. Project leaders can be old and wise without being old and wise; they've already done this project 1000 times (albeit in the mind of a machine), so they've got a good idea how long it might take.
Using this approach, you could build absolutely anything into your model; Productive day averages 6 hours, but varies between 2 and 20 hours on occasion? Sorted. 0.04% chance of aliens abducting your senior developer? No problem, at least for the project. The options are endless.
Nicer still, because this approach uses simulation rather than algebra, we don't need to be too anal about how the parameters are set. If it's easier to say "95% of the time it'll take 5 hours, but 5% of the time it'll take a random value between 8 and 10 hours", then that's fine. We don't have to put together some strange combination of probability distributions that models this; we just run with it. Equally, if you have a set of example data to use as a basis (well, this system has N classes, and it took X long), then these values could be used directly, without having to build a complex model from them first. That said, if the guys doing the estimating do understand probability, then they can use a Poisson distribution to determine how many use cases will be delivered by a week next Friday if they so desire.
Equally, because we're actually running the project, we can apply all sorts of interesting things to the model that would be impossible using a purely statistics driven approach. For example, in an agile project, we can simulate the team size and length of sprints against the simulated sizes of the products to determine the optimum length of a sprint for the project. We could simulate the quality of deliverables based on whether code reviews are expected, and use this to estimate the impact on the length of the test cycle. Obviously, this stuff is a bit trickier to achieve than answering the usual how long/how much question, but it's always good to know there's scope to develop things further in the future.
The architecture underlying this kind of estimating machine is pretty trivial. I'd say, with 100% certainty, you could deliver the underlying engine in 27 hours, 5 minutes. Elephants and petunias not withstanding.
A colleague just pointed out a brilliant article from Joel on Software discussing the upcoming release of Microsoft's IE8. If you care about the web, have a position on web standards, consider yourself an activist, pragmatist or martian, then read it. Now.
Apple yesterday released updates to their AirPort Extreme and TimeCapsule base stations and Time Machine which allows Time Machine to use an AirPort disk for backup (I have an extreme with about 1.5TB hanging off it). Finally. For those of you with a laptop like me, this means you can have a safe and secure Mac without living life in a bird's nest of cables and disks.
I configured it with a new disk yesterday, and it works great - just connect to the drive (by clicking on it in the left bar in Finder), and it appears in the Time Machine window and can be selected as the target for backups. The good news is that it seems very stable and happy - putting the laptop to sleep and waking it up again during a backup seems to have no impact, which is great. The bad news is that I started my first backup more than 24 hours ago, and it's still running. Whoops. Learn from my mistake: do your first full backup with the drive physically connected, otherwise you'll spend the next three weeks watching paint dry.
All in all though, it's great news that those of us that invested in AirPort Extreme base stations are being given the same privileges as those investing in brand new Time Capsules.
