It is always annoying when people expect you to collaborate with them and they send you locked files.

This trick only works for documents that are protected for Review. Not when you can not even open them.

So, let us assume you have a Protected.docx file that looks something like this. Notice the disabled Delete Comment, Accept Changes and so buttons.

Step 1: Open the box

A good thing to know is that .docx (and .xlsx) files are just zipped folders.

Rename the Protected.docx file to Protected.zip and unzip it. You will obtain something that looks like this:

Step 2: Tinker with the contents

Open the file word/settings.xml. Its contents will look somewhat like this (except there will be more of it and everything will be on the same line):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:settings xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w10="urn:schemas-microsoft-com:office:word" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:w14="http://schemas.microsoft.com/office/word/2010/wordml" xmlns:w15="http://schemas.microsoft.com/office/word/2012/wordml" xmlns:sl="http://schemas.openxmlformats.org/schemaLibrary/2006/main" mc:Ignorable="w14 w15">
  <w:zoom w:percent="100"/>
  <w:proofState w:spelling="clean" w:grammar="clean"/>
  <w:trackRevisions/>
  <w:documentProtection w:edit="trackedChanges" w:enforcement="1" w:cryptProviderType="rsaFull" w:cryptAlgorithmClass="hash" w:cryptAlgorithmType="typeAny" w:cryptAlgorithmSid="4" w:cryptSpinCount="100000" w:hash="1+kEXOhPYpKExv2F8dIx9VCN5Ps=" w:salt="aOdV7QoW4ZJW3KVDxd7jBg=="/>
  <w:defaultTabStop w:val="720"/>
  <w:characterSpacingControl w:val="doNotCompress"/>
  <w:savePreviewPicture/>
  <w:compat>
    <w:useFELayout/>
 ...

Notice the

<w:documentProtection w:edit="trackedChanges" w:enforcement="1" w:cryptProviderType="rsaFull" w:cryptAlgorithmClass="hash" w:cryptAlgorithmType="typeAny" w:cryptAlgorithmSid="4" w:cryptSpinCount="100000" w:hash="1+kEXOhPYpKExv2F8dIx9VCN5Ps=" w:salt="aOdV7QoW4ZJW3KVDxd7jBg=="/>

this is the source of our woes. Now, simply remove the characters between <w:documentProtection and the first /> you encounter after it. Save the file.

Step 3: Put the box back together

Now, zip the folder back again. It is important that you compress the files as they were: the folders word, _rels, docProps and the file [Content_Types].xml are on the top level of the zip (i.e.: not in a subfolder that was probably created when you unzipped the original file). Let us call the new file Unprotected.zip

Finally, rename the file back to Unprotected.docx.

Step 4: Look into the box

And voilà:

Note: Word might complain about the document being corrupted, simply choose Open Anyway and re-save the file again.

It is interesting that when you move, suddenly everybody you talk to has a cousin with a moving company.

And then they are disappointed that you have went with a professional rather than gamble on a small, family-held, business.

I had a problem. First I have set up an UITextView with these parameters:

view.backgroundColor = UIColor.blueColor()
view.text = "An example text"
view.textColor = UIColor.whiteColor()
view.textContainerInset.top = 0
view.textContainerInset.bottom = 0

I wanted to be able to centre the text in the view vertically. This should be easy, one just needs to position the top of the text according to the formula: top = (container.height - content.height) / 2. However, when you look at the actual look of the UITextView you will see this:

view.font = UIFont.boldSystemFontOfSize(100.0)

view.font = UIFont(name: "DINCondensed-Bold", size: 100.0)

Ouch, there is a semi-randomly placed offset at the top of the text. Turns out the point size of a font is not always the one you have demanded. However it is possible to get the actual height. An UIFont class provides a bunch of useful metrics:

view.font = UIFont.boldSystemFontOfSize(100.0)
view.font.capHeight // 70.5
view.font.pointSize // 100.0
view.font.ascender // 95.2
view.font.lineHeight // 119.3

view.font = UIFont(name: "DINCondensed-Bold", size: 100.0)
view.font.capHeight // 71.2
view.font.pointSize // 100.0
view.font.ascender // 71.2
view.font.lineHeight // 100.0

On a graph this would look like this:

Finally, the method you can now use is:

extension UITextView {
  func centerTextVertically() {
    guard let ascender = view.font?.ascender else {
      return
    }
    guard let capHeight = view.font?.capHeight else {
      return
    }
    view.textContainerInset.top = (view.bounds.height - ascender - (ascender - capHeight)) / CGFloat(2.0)
  }
}

Note that this will only for one liners and only if you know the height of the UITextView (i.e.: the height was given to it on creation)

The rumour about Apple removing the 3.5mm jack in the future iPhone has wreaked havoc around the Internet. There are several arguments for and against it, but I think there is only one that is valid: it would make it impossible to create accessories for iPhone without going through the MFI process.

Case in point, Apple has recently featured this application in their advert “Ridiculously Powerful”.

This application would probably never exist without the possibility to leverage a cheap and universal interface with the device.

Here is a theory. There have been quite a lot of rumours about a new “iPhone 6C” which ought to have the 6’s internals in a brand new 4” plastic body. However, with no parts leaks this late into summer, the existence of this model is not a given. (side note: there are no leaks for the iPhone 6S plus out either)

We know that Apple has already broken the pattern of older devices moving down the price range with the 5C. I think this year the pattern could be broken again.

After the iPhone 5C was introduced, the Internet was swamped with articles describing how much of a flop it was. The reality is that most people who buy iPhones in October buy the latest and beefiest one.

So, what if Apple introduced the new, plastic, iPhone 6C in September but only made it available in shops in December for the holidays? This would give them approximately until October to ramp up the production, which would explain the lack of the leaks.

Not only would they protect themselves. But they would also get an excuse for the lower number of phones sold.

Edit 2015-09-14

Well, first predition, first failure. My score so far: 0 out of 1.

I’ve decided to simplify the website’s source. I went from 20 SCSS files to one. My goal is to serve no cruft. I’ve gone through all superfluous classes (bye bye clearfix). The grid is gone in favour of flex.

I’ve added my GitHub page to social links and changed the icons to SVG.

Next step is moving Gulf to GitHub, getting rid of jQuery and finally; writing.

I wonder if the people who complain about the Monument Valley in app purchase also think that paying $30 for a Starcraft 2 expansion is preposterous. After all, they’ve paid 60 bucks already, no?

Maybe sequels to movies should be free too while we are at it.

This has been in Rennes for some while now. One has to wonder what this particular person’s feud with Google is to express their hate like this.

In any case, it is quite an impressive feat.