Probably something everyone but me knew already, but at least next time I will have to do something similar I’ll have a trace.
My original Bootcamp partition was a smallish thing at the end of the first disk I had in that machine. I have bigger needs and a new disk and all that jazz, so I want to clone the partition to the new one. Forget about disk utility for that, NTFS is not its forte, I’ve had weird partition size issues with it, so I use clonezilla, which works better, performs checks and repairs and is overall smarter.
I could restart on the CD and have my computer doing nothing but that for a couple of hours, but I would rather use VMWare Fusion.
I have prepared my new partition as ExFAT on the mac (the closest it knows to creating a new NTFS one). By default, Bootcamp virtual machines grab the whole disk for the purposes of booting (even though it only uses and unmounts the NTFS partition), so I decided to use the same for the new one.
VMWare won’t let you add an existing disk directly using the UI but it does work with command line. Using mount I check which disk has the partition I want to use as destination
/dev/disk2s1 on /Volumes/WIN7 (msdos, asynchronous, local, noowners)
So disk2 is my target.
With VMWare, you can create “proxy” disks for existing real hard drives with the command vmware-rawdiskCreator. So I create the vdmk file
$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-rawdiskCreator create /dev/disk2 fullDevice ~/Desktop/Win7.vmdk ide
For some weird reason, the VMWare Fusion app won’t let you add that disk as is, so you need to right click on the bootcamp virtual machine, reveal it in finder, open package contents and edit the .vmk file. At the end of the file, I added
ide1:1.present = "TRUE"
ide1:1.fileName = "/Users/zino/Desktop/Win7.vmdk"
ide1:1.redo = ""
I then added the Clonezilla iso to the virtual CDROM, set the machine to boot off of it, and clicked start.
Clonezilla has a plethora of modes, machine to machine over the network being an awesome one for instance, but what I want to do is first check the partition is the right one and formatted correctly.
So I enter the command prompt and fdisk the drives. There should be 2, sda and sdb, one being the source the other the target. Use the “p” command within fdisk to check the partition scheme and the availability of the disk. For me, the destination partition was sdb2. So I formatted it to NTFS:
$ sudo -i
# mkfs.ntfs -Q /dev/sdb2
Double check everything if you are unsure of which partition you will completely erase! Do not come back to me afterwards complaining your disk was erased… My partition was the 2nd one of the 2nd disk (sd b 2), but yours might be different.
Then go back to the clonezilla menu, select local, then local partition to local partition, choose the right ones as source and destination, and enjoy the show.
Well because that way I could write that post while it was doing the transfer. Because I trust clonezilla with copies, with all its smart things and its checks, even if it’s kind of daunting if you fear the command line. And because I generally hate the idea of having a computer stuck for hours on something that uses les than a percent of a percent of what it could do.
Oh and because that way I can tell people who didn’t know about the way of mounting real disks into VMWare, and give a shoutout to clonezilla.
Let me know if it’s useful to you!
If you know me a little bit, you know I’m a sucker for space stuff. And research in general. Doing something that has never been done before, or furthering an agenda that goes into that direction has always been something that gives me goose bumps in an awesome way.
2014 has been a wonderful year for space buffs, but two very recent missions have hopefully recaptured the interest for everything interplanetary, Rosetta/Philae and Orion.
“It’s like hitting a bullet with a smaller bullet, while wearing a blindfold, riding a horse”
In march 2004, some people thought it would be a cool thing to achieve. Rosetta was supposed to come close enough to a comet to take detailed pictures and perform analysis, why not try to land on it too with Philae?
Think about it: a route spanning 6.4 billion kilometres in 10 years, to hit a rock 4 kilometres in diameter ( 1/1600th of Earth ). Mind boggling. And yet, it was done, in the name of science. There are a lot of reasons to do such a thing, and the ESA explains it nicely.
“To Infinity and Beyond!”
Earth isn’t doomed just yet (even though it’s getting there), but we all know in a corner of our minds that we will have to leave it for another planet at some point in the future. Almost 50 years after our first baby steps in interplanetary travel and the Apollo Program, NASA tested a new craft designed to take us back to the Moon, and even Mars. Even if it’s currently empty, it signals a commitment to a spacefaring culture once more. Sure, we are nowhere near having a solution for interstellar travel, but when we start colonizing the Solar System in earnest, we’ll be closer to the stars.
THIS is why funding research is important
Does it make any difference today to know what that comet is made of and what it’s seen during its travels? Does landing on mars allow me to have a summer house there? Of course not. But our grandchildren will be thankful we didn’t spend to much time navelgazing as if the universe was restricted to Earth.
As of Xcode 6.0.1, you can only generate an IPA with a certificate/provisionning profile pair that matches a team you are part of (it offers only choices present in your Accounts preference pane).
Before ranting about why this this is stupid as hell, here’s a workaround:
xcrun -sdk iphoneos PackageApplication [path to the .app] -v -o [path to the ipa] --embed ~/Library/MobileDevice/Provisioning\ Profiles/[profile to use] --sign "[matching developer NAME*]"
NAME is the name that appears in the popup menu in your xcode build settings, not its ID
After a somewhat lively discussion on Twitter about that, two things:
- I know Apple would prefer that developers are organized in teams managed on their servers. It’s just not practical for a lot of them, and there’s even a few good reasons not to go that way
- It’s stupid to have that drastic a change, when 3 weeks ago, the official way of having a third-party developer generate IPAs for your company was to give him a p12 and a .mobileprovision and let him do his thing, and to not warn people about the change
For those of you who don’t know how development of a mobile application works, yet, here’s a quick run down.
A customer contacts me for a development. We agree on a timeframe and a price. I write the code, provide them from time to time with testable betas. When we agree it’s finished, I give them the final IPA for putting on the store and we call it a day.
Providing betas and giving an IPA for the App Store work exactly the same: a binary is produced, which is put in an IPA (kind of installer package for iOS), then that IPA is signed, and transmitted. On the other end of the wire (be it the customer or the App Store), the IPA is decompressed, the signature checked for validity (by app ID, device, and status of the apple account), and the app can be run or put on sale.
In that scenario, if I use my certificate, I have to enter the device IDs the customer will test the app on, of which my developer account allows for 100, in total. So if I have 10 customers with 10 devices a year, I can’t work anymore. So, most of the time, the customer has to provide the relevant information for me to give access to the betas, and of course, since they’re releasing it under their own name, the relevant information to produce the final version, which is a different pair of keys.
So far, so good, all they had to do up until now was give me a couple of p12 (key archives) and the corresponding profiles, and manage themselves the test devices, the release, etc.
It allows whoever’s in charge to retain access and knowledge about what the company is doing. Does that person want me to see they are also working on a concurrent product to something I’m doing for somebody else? Of course not. And there’s no reason to give me that kind of access. Oh and if the customer wants to prevent me from using that certificate again, all they have to do is revoke it.
The new way of doing things is to have the customer invite the developer in the team (in the Apple sense of the term), which gives the developer access to every piece of information under the sun (even when we can’t use it directly).
This is part of an ongoing cycle of making life difficult for contractors. We always have to find workarounds. The idea that almost every ios/mac developer out there is writing code for the structure they belong to, who will then release it in their own name for the general public is ludicrous. It hinges on something that has been gnawing at me for years: the idea that code and binary are the same thing, and is what I’m selling.
That idea is false. When you get Unity3D for your game development, you DO NOT GET THE CODE. For Pete’s sake, we don’t get the code of the OS we are developing on! The idea that when a developer is hired, the customer automatically owns the code is one of the many fallacies I have to deal with on a monthly basis. You hire a developer for his/her expertise first, and foremost. It might be then applied to internal code, which the dev won’t own in the end anyways, or to a newly minted piece of code which might or might not be given with the ability to use said code as part of something that has value. It is a separate item on the negotiation list.
I might delve into the pros and the cons of giving out your source code with the binary in a later post, but let’s get back on topic.
If, like me, you don’t always give the code with the binary to the customer, you’re screwed. Of course they won’t give you access to their company’s secrets by adding you on the team, if they don’t want to. And, obviously, you can’t release the binary under your own name for a customer who wants an app.
Please give me back a way to sign IPAs for customers, directly from my IDE.
Thank you, and sorry for ranting.
Remote Workers Are A Pain To Manage (sic)
This is not exactly news anymore, but a fraud-related scandal was uncovered a few days ago in the US patent body of regulation.
This hits me on two different levels, completely unrelated to one another : work-at-home mechanics, and the actual concept of patenting stuff.
My distrust of any patent system (especially for software) in today’s day and age has popped in once or twice already.
The work-at-home side of this story is distressing to say the least. In the last 15 years, I have worked for maybe a couple of months in an actual office with actual people. It’s no secret I don’t enjoy it, and it’s no due to any of the fine folks I was sitting next to. It’s just that my habits of cursing loudly at my screen, and my need for a total lack of distraction when I’m focusing on a particularly thorny problem, make having people sitting right next to me a difficult fit.
But because of stories like this, and because it is so easy to cheat bosses/customers of actual working time when they don’t have their eye resting directly on you, working from home is a very real deal-breaker for my interactions with customers sometimes. Trust issues aside, on an hourly basis, I get more than regular employees, and I can Do It in my bathtub! Holy granola! From the outside it looks like I have some totally unfair advantages over everyone
As Seen From The Other Side
Truth be told, working from home is hard.
Let’s start with the beginning of the day: it’s so easy to snooze the alarm and go back to bed. Really. Especially if you have been working late the day before. Then whatever your routine in the morning might be, taking your time to read the news, catch up on social stuff, etc is tempting. Then you realize it’s really late and you might have to cram everything before lunch, which could last longer because you’re enjoying it in front of the TV, etc etc…
Basically, if you have any procrastinating tendencies, they are all very easy to succumb to. Structure helps, like having “office hours” to simulate the real thing, planning your customer phone calls early in the morning, or at any other time you might be tempted to do anything else but work. Life hacks such as this are easy to implement and adhere to, and every one should know themselves well enough to know which ones are important and how their personal procrastinating tendencies surface. Because the key thing about working from home isn’t replicating a workplace at home.
To be able to work from home, you need to know exactly how your brain works.
To take the only example I know well enough, I tend to be very code efficient right after I wake up. So I have two known times where I cram my most urgent/important stuff : early morning, and after my nap. Yes I do take naps, partly because of this, and in a regular office, it’s not generally the norm. After roughly 2h straight of coding, my mind tends to wander. I start checking news, chat with people. So I use that time to do my support / client stuff. But even that is tiring, so I generally cap that out at 1h. Then I do the code that’s less neuron-consuming, which might (or might not) get me in the zone again for more important stuff.
The important part of all this is that I spread my work hours larger than strictly necessary. I usually have a 8-8 work day, and I sometimes work for a few hours on week ends as well. Because I can, and because it doesn’t impede on other things I consider vital. And during the day, I have free time to run errands, have a cuppa with people, etc. The very fact it’s spread out a bit means that I can contract it if necessary to stay on a deadline that is whistling dangerously close, or expand it a bit if I have time and am feeling under the weather or uninspired.
The Root Of The Problem
Applying “office rules” at home seems completely stupid and backwards to me. Either you give people the option to work from home until they can’t achieve what they said they would do anymore, whatever way they want to organize themselves, or you force them to be under scrutiny in an office. Giving them restrictions in their own homes will lead to resentment and “cheating”, and there should be no shame in saying after a while “look, it doesn’t seem to work when you do it remotely, come back in an office”, to potentially be tried again at a later date. The remote workforce problem embodies to me a fundamental flaw in how people’s work is valued : results vs time.
It’s perfectly ok for people whose job it is to be available (to interact with customers who may or not call, for instance) to be paid / valued in good part relative to the time they spend on the job. But for developers, to take an example I know only too well, it’s all about what we do deliver. Time is second.
Let me take an example. Company A contacts me, for a contract on an app that displays news for their product and allows for support contact, and social sharing. The very first question they ask is how long it’s going to take. Which is fine and normal. But based on that, they derive the amount of money they will assign to the project. While my time is as valuable as anyone’s, we can all agree that there are some things I will do faster than others with my level of experience (to take the seniority out of the equation). If it takes a colleague of mine 1 month to do that app, and I take only 2 weeks, should I be paid less? No but the second question they ask is “what is your daily rate?”. So in essence, if I have a fixed rate that’s close to the market I will be paid less for the same job, and if I double it, I probably won’t have the contract. How is that fair?
I can hear sniggering in the back : “why don’t you just SAY you will take a month?”. The ethical value of that comment is left as open for debate.
But once again, we circle back to the problem of assigning a value to someone’s job, and the perversity of contemplating cheating to “fix an intrinsic wrong”. I refuse to think every single human on the planet is prone to cheating in every circumstances. Most of the time, mostly honest people who try to game the system to do less while earning the same financial compensation feel cheated themselves. It is indeed a HR problem, but not in a “let’s put more restrictive measures in place to increase productivity” way, more in a “let’s see why these experts in their fields feel like they aren’t paid enough”. And remove the actual bad apples based on results.
One of the things to handle when you have publicly available software out there is what the users’ response is like.
For Highlight 2, it was overall pretty warm and nice, except for 2 general things :
- “I can’t scroll the window under Highlight” (1 star review) : Well… yes. A computer has windows on screen that take active user inputs, such as keyboard and mouse events. It’s really an either/or situation where there’s no way to determine if that particular time you wanted to click through or draw a point. Not to mention more modern OS feature some security features that specifically forbid and prevent your app to access another’s memory (and a window is part of the app’s memory). So… well, yea.
- “It doesn’t work on top of Keynote” (2 stars review) : For reasons not dissimilar to the point above, this is currently not feasible. To get a little bit technical, it’s a matter of screen capture, kind of like in games. Basically, the app expressly states it wants the screen(s) for itself. Unless you have a way to insert yourself in the graphical pipe (through the graphics driver, for instance, which is how NVIDIA does it for its Shadowplay features, or through the graphical library like Steam), there’s nothing to be done. And as a small fry developer, I don’t think I will have any way to install a potentially harmful kext ( Kernel Extension) in the App Store.
Moving on to the things that made me laugh (and far more numerous than I thought):
“Why don’t you market it?!? I’ve never heard of it before today!” : Hmmmmm. I’m lazy, that’s all. I kind of want to see it have a life of its own. It’s not free, granted, but it’s clearly not geared towards massive profits… What should I do? post an ad? go talk about it on a show? Come on people, let’s be real :)
“Do you want to make tons of money with it? if so, please contact me” : See above, with more laughter.
It’s been a long time coming. Between my projects with quite in depth dives in BTLE and CoreData (and the various more “classic” iOS development shenanigans) and the fact precious few volunteered to beta test HLT2, I didn’t have much time for getting that release up to publishing standards.
It is now a done deal and the 2.0 version has been submitted to the App Store.
New goodies include one of the top demands for that app, text input. Historically, my main concern about text input had been the potential clunkiness of dealing with a UI that would make sense in a totally mouse-oriented application. I found a solution that seems to be a good compromise : any double click on the screen will bring up a text input bubble (with the color of the pen it will use as a border, because, well, I’m forgetful sometimes). You can obviously setup the font you want to use in the preferences.
The main problem with that, though, had to be technical : NSPopover doesn’t work well at all with multiple screens (radar submitted), so I had to make my own, based on some existing code, but still mostly debugged line by line to work as intended.
Anyway, it works. It’s one of these “it looks easier than it is” things to implement, but it’s there.
Thanks to the bug reporting tool, and kind users sending me emails, I also managed to fix various issues with multiple screens, and laptops, as the dynamic nature of what a screen is wasn’t factored in properly. It now is.
And finally, the old method for global system shortcuts was wonky under more recent releases of the OS, so that had to be redone as well.
Anyway, I’m glad I finally managed to push it out and keep my fingers crossed for the validation by Apple. Hopefully, the 2.0 release of highlight will hit the store in a few days.
Keep sending me feedback, as it motivates me to inject new things in that project! And thanks a lot for making this app a bigger success than I hoped for!
As you can see, I have started to update this blog more often than in the past… This is part of something I keep telling people who want to freelance/go indy, and I have had little time/motivation to carry on myself.
Being without boss means self-regulating every aspect of your life. When to work, when to relax and let inspiration come, when to immerse yourself in code despite all the distractions that are freely available to you.
Back when I started this blog, it was mostly a place to put some interesting tidbits about code I found during my projects that might benefit others, but over time, it became harder and harder to make snippets that would make sense outside any context. The various technologies I can credit myself for knowing intimately are not prone to simple 20 lines examples, and this led this place to have more and more empty time between posts.
Having gotten over the latest rush to have a product shipped, I decided to apply the discipline needed to work alone to this blog as well. I apologize in advance if some of the entries are bland – or completely uninteresting for that matter – but like with everything else, if you don’t practice something often and rigorously, you loose the aptitude and the momentum.
As a side note, getting motivated to do something is kind of a trick question in our line of work, as freelancers. It should be as simple as “I said I would do this” and do it. It might be hard sometimes, but put yourself a reminder that auto renews every so often days, and just do it. No boss means more freedom in terms of daily planning, but no one ever said it meant less work.
HLT2.0 is reaching RC stage. Please apply for beta testing!
If you haven’t bought HLT yet, I will give you a promo code, if you have (thank you) you will participate in the Circle of App Life : only requirement is to be able to submit bug reports in a clear way ;)
Nothing new to developers but for some reason sometimes hard to grasp for the profane, the development dance is something that should be taught in schools.
In the mind of the non technical customer/boss, “development” is the process of going from nothing to a highlighted goal (specs, screens, that kind of things).
Most of the time, if you do a whole project with only developers attached to the process, for us code monkeys, it’s more like building something with Lego(s; bricks) : we build something that works, then iterate towards something like an ideal.
Cultural clash happens when the goal isn’t realistic from the point of view of the dev, but is non negotiable from the point of view of the non dev.
Which leads to the Dance : we take a few steps back on the goal, then a couple of steps sideways, then a few steps forward again.
Non technical people have to understand that’s the only way they can get close to what they want. Because the technical side is fraught with pitfalls, unwanted deadlines, miscomprehension, etc. Many a good feature started as a “what if?” coming from down below, only made possible because the foundations allowed them.
Going for a strict top-to-bottom approach gives you apps or websites riddled with bugs (because, as hard as you try, users will always use your work in a way it’s not supposed to support, or that you didn’t think of), and a strict bottom-to-top approach gives apps that are bland or ugly or without global vision.
Only a smart collaboration of the two can result in a decent product. Agree on key features, on a way the program should be handled in a way that’s considered normal, and fill the blanks as you go. That way, devs can geek out and build foundations that will handle anything and everything that they can think of, without having to fear you will change your mind once the hard work is done, and the non-techs can leverage the tech savvy to get something that will satisfy their itch of a beautiful, sensical product.
As with any relationship, concessions have to be made, and so far, the dominant culture has mostly been that developers don’t – and shouldn’t – have any input on the project, that developers are executants. What more companies get in return is a passive aggressive stance of “I’m going to do exactly what you asked, so that you can see it fail miserably”.
I won’t go into details, the WWDC keynote has been covered far and wide.
- New Look : √
- New APIs : √
- New ways to do old things : √
- New Language : errrrr √
Response among the community was unanimous, this is xmas come early. And it’s true that for us developers, there a lot to be excited about. The new “official” way to communicate with other apps through the extensions mechanism is awesome, the integration of TestFlight will make a lot of things easier, especially for us small teams, and the new language will hopefully make us more productive (yay, less code to write).
There are some blurry or grey areas about these changes that will probably cause some problems, but hey, we’re Da Dream Team, right? We’ll manage.
The only thing that struck me as a slight cognitive dissonance is the fact that outwardly, Apple publicly recognizes our role in the success of the platform (huge), but kind of changes nothing in the way we are treated. I am definitely not asking for exclusive access to the thought process of Apple regarding what’s secretly being working on, I think opening up betas to pretty much everyone defuses the rumor mill, and might help get better .0 releases.
Since we are the people who make the “normals” want to get an iPhone/iPad, why is it so hard to have any handle on how we do it?
Xcode tends to get better, but there is still no way to expand its capabilities, or adapt it slightly to the way our brains handle code-writing. Third party IDEs (like AppCode for instance) that may not be perfect by any stretch of the imagination, yet still give us more flexibility, have a hard time adapting to the internals of the build process. We still have proprietary/opaque file formats for vital parts of the development (I’m looking at you XIBs and CoreData models). Cocoapods have become mainstream, but are still iffy to integrate (and might break).
For the social side of things, since WWDC is harder to get to than a Prince concert, same deal, it’s Apple’s campus, or community based (read no help from Apple whatsoever) things. Kitchens? Local dev events? Access to labs? If you’re not in California, tough luck.
So, yes. We are the main booster for the success of the platform, but we have absolutely no handle on things, in any way, shape, or form.
Am I excited that we get shiny new things to play with? Sure. Is my head buzzing with ideas? Yup.
But I am also a bit bitter that, sometimes, it feels like we’re not working together.