I’ve been lazy. I switched to a mac a long long time ago, and my dream since then has been to finally stop using windows altogether.

I’ve not enjoyed Windows since nautilus, which never actually got a release, and we’re talking 1996. But I love .net, amongst many other ecosystems I enjoy working with, and so I’ve had VMWare installed as a faithful companion for a long time. But the performance sucks, and VMWare just fired everyone on that team to send the work to China or what not, and with .net core getting a story on unix platforms, it’s more than time that I accept that it’s not him it’s me, and move out.

This serial will be all the things I am doing to live my life away from Windows, both to force me to give the ring back, and to make sure I learn how to date again, in this instance, macOS (stil called OSX by some people for now, but meh.)

Early warning, I have no idea what I’m doing, so any comment / feedback / tips / cool tools to make the transition smooth, use the comments! Another warning, this entry is open to guys of all genders, shapes, colors, planet of origin, it’s a play on words on a popular TV show I never saw.

Shell, shell, shell

The shell is a bit like the command-line that you already know, be it cmd.com or powershell.exe. But not quite, so let’s review just the basics to get you started.

Start the Terminal, or Terminal.app, and put it in full screen, which is the little green icon on the top left of the app bar. There you go, plenty of space to play with for now.

The prompt

By default, the prompt shows you a bunch of things: the computer name, the current user, and where you are, followed by a $ instead of >. After all, money beats greatness, right?

When I start my terminal, I see the following.

  cherenkov:~ serialseb$

Cherenkov is my machine name, and like all my computers is named after anything to do with light. As an aside, it’s named after the cherenkov effect, where protons and neutrons are thrown at close to the phase speed of light, but light is slowed down by heavy water, and so those particles travel faster than light in that medium, resulting in a lovely blue halo. You can’t say you don’t learn things on here!

Moving around

cd still works, but like most modern operating systems (and technically NT too, but we never use that), things are not in the same place, because everyting starts at /, which is the root.

Thankfully, you already know that, because when you go to a website, say, https://serialseb.com, it’s actually https://serialseb.com/, so you should already be comfy with the idea of a root.

There is no place like home however, and you’ll probably end up in your home directory often. This is the equivalent of C:\Users\yourusername\, and we can navigate to it using cd ~, which is equivalent to cd ~/, where ~ is your home directory. Makes all those websites of the 90 that were at http://corp.example/~username much more understandable! And thanks to @jasonimison, you can just use cd for the same thing.

To list things, no dir command, we replace it with ls. On its own, it can be rather confusing, so the equivalent to the windows experience seems to be ls -al.

Install all the things

When you’re in a shell, the last thing you wanna do is go download package files from a web site using clicks everywhere, cause let’s face it, it takes using the trackpad, and the keyboard is your friend. So the first step in doing anything useful on a mac is to install homebrew.

Homebrew is a command-line package manager, not dissimilar to chocolatey, but without the MSIs.

To install homebrew, we need a version of ruby that works. Thankfully, Apple provides us with a bunch of things in their Command Line tools, so let’s go ahead and install that.

cherenkov:~ serialseb$ xcode-select --install

Agree to sell you first-born child, wait a short while, and you’re ready. Now let’s install Homebrew itself.

cherenkov:~ serialseb$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

You can now install tools from the command-line very easily. Everything else in this serial will require this basis, so tap yourself on the back, you took your first step to moving on.

It’s not necessarily the destination that matters, but let’s make the journey as fun as we can!

The next blog post in the “Public Speaking” serial is being written, but I’ll probably hold off from publishing it for a few days.

Thankfully, the stellar Hadi gave me a great excuse to write about something else.

Let me use a 404 when I mean a 403.

— Hadi Hariri (@hhariri) January 29, 2016

In HTTP, URIs are identifiers. Well-behaved ReSTful systems expose all identifiers as URIs. And depending on a URI, the presence or absence of it may provide a lot of information to a potential attacker. I believe people call that information disclosure.

To prevent stuff from leaking, some people like GitHub and the HTTP specification, can advise you to respond with a 404 NOT FOUND when in fact you are just not authorised to see a resource. In other words, I won’t tell you if you have the rights or not, I’ll just put that resource in my secret place where I hide my best cakes and tell you I couldn’t find it.

The good

A practical example of this is when trying to authenticate yourself when accessing a private repository. An attacker wanting to get access to your source code, say by finding a way to hack into github, would want to verify if the code for your web app is indeed on github, private repo or not.

One would think that they would have to find the correct repo name anyway, and that it does not matter. Unfortunately for One, stuff leaks all the time when exceptions get generated, as many sites will forget to turn on custom errors, and the path to each file used in compiling a site may reveal enough for the hacker to make an educated guess. It only needs to happen once.

The bad

Unfortunately, because of this approach, if you try to clone a repository for which you are not permissioned, git will tell you that the repository doesn’t exist. Usually ensues hours and hours of debugging for the poor developer trying to check code out, as I saw many times at one of my previous clients, until someone remembers that the guy was not added to the org, or to the repo.

This is a situation where security trumps usability, as giving any better notification to a user may well give better notification to hackers.

The ugly

Now, that’s the theory, and it’s pretty compelling, because it’s a conscious tradeoff. Unfortunately, if you apply this blindly, you’re making a tradeoff you probably didn’t consider fully. For if you want to prevent information disclosure, the status code is just an explicit one. Time is of the essence, and hacking your system can be done by simply looking at your watch. I’ll give you two examples.

A lot of server applications are built by separating the HTTP-serving part of a request, and the application-part of the request. On windows boxes, IIS may respond to a 404, but so would asp.net. They are however different 404s, and windows leaks like a prepubescent guy on his first date. Custom Server headers, vanity response headers, you name it. From this, it’s easy to know if an ASPX file exists or not, based on if IIS or asp.net responds. So that’s the first thing you need to ensure is not leaking.

But even once you remove all those vanity processes, the timings are different. IIS will respond with a 404 substantially faster than your custom authentication code. By definition, something that is not there does not require processing the token / cookie / ticket the client is providing. The solution here is to always process auth information, before trying to see if a resource exist or not, and before doing any authorisation.

Once you do that, if you have your own password management, and you do it right, you’ll have a salt, a hashed password and a number of iterations that is used to generate that hash, with some key padding in there. This stuff takes time, on purpose, as they prevent anyone that stole your DB from brute-forcing their way through the decoding, in theory. The higher the iterations, the longer it takes.

So even if you implement all these things, you still need to be aware that a user account not found will always respond faster than a user account with the wrong password. And if you think an attack of that kind cannot measure the timings from a laptop, sure, you’d be right, but it’s trivial for me to get myself a server on the hosting platform you use for your system and run it on a high bandwidth environment where, statistically, i could find out if that user exists or not.

How do you prevent that kind of information disclosure is more complex. My best guess and proposed solutions before have been to always delay the 404 response by the average response time of users that do exist. It requires having good stats on that, but that way someone from the outside really cannot make any supposition.

Security always trumps usability?

There you have it. I do believe that a public website should always privilege preventing information-disclosure to usability, but if you already leak a whole bunch of data, making your system more opaque doesn’t protect you and confuses your users. Don’t leak at all or be friendly. Then again, you always have the possibility of designing your URIs so they cannot be predicted from externally available information, and then you don’t need to do any of this.

I got into speaking because I kept trying, in no small part thanks to the many user groups that litter our country with safe and fun environments to push our boundaries. I’m not sure if I progressed as a speaker, but I’ve learnt a bunch of tricks and practices over the years that I’ve found useful.

Know the why

It’s terribly important to ask “why”. Why are you on stage? Why do you want people there? Why do they come? Why is any of what you say important, relevant or useful to anyone? Why should anyone listen to you?

It may sound like a therapist’s notebook, but it’s much simpler than that. A talk is a moment for people to take something away. You want to focus on what people will take away, and to do that you need to target your content. If you stay focused on the key message, you can start editing irrelevant content out.

It’s ok to have a talk with only one key takeaway. It’s fine to go to a Kebab shop and get a Kebab. Kebabs are great, mostly healthy, and people go to a Kebab shop knowing exactly what they’ll get. As long as they get their Kebab, they’ll love the shop, enjoy the Kebab, and the rest of their night. Be a Kebab.

The stage is your best friend

The stage, or the desk, or the chair, or whatever is used to delimitate where you belong, can be frightening. Like most frightening things, the best way to get over it is to conquer it. Take a bit of time to look at where your laptop will be, where you will be able to see your screen, and where you can walk to.

Go and sit in the audience chairs at the beginning, on all corners. People are coming to see you, so you want them to see you. Putting yourself in their shoes is a good way of knowing what your stage presence will look like.

Test the projector first. See if your content is in the right format (4:3 vs 16:9 can ruin good slides). Check the sound system, if you use a mic. If going voice only, ask one of the organisers to sit at the back, and talk as you normally would. If they can’t hear you, adjust your voice to be louder.

Don’t be afraid of being afraid

Everyone gets stage fright at some point. I get very stressed the night before my talk, and the anxiety continues all the way to the talk. I arrive early, plug myself and the laptop in, put the screen on the first slide, and then proceed to pace up and down, ignoring the audience and absorbing myself in my own thoughts. I just think about conversations I could be having, food I had for lunch, or even just the colour of the wood on the stage. Nothing about the talk for a few minutes.

I need the time off before I start. I don’t look at people, I try to completely ignore them. I’m preparing myself by just being there and absorbing the environment, getting calm by pacing, walking on the stage to own it.

Start the delivery

When you’re on stage, you want to be focused on your delivery. Yet, so many things get in the way. My hands! My arms! My posture! My shirt! Oh, the stress, the incomprehension, the awkwardness of it all!

Most of us don’t realise how much work is involved for people on TV to look natural. Switch to a news TV channel, and look at how they sit, and where they place their hands. Now ask yourself this question: have I ever held the tip of the fingers of one hand in the other, while talking? Of course not!

We have been pre-programmed to find hands and arms hanging on the side as an unnatural, awkward sign that the person talking to us is just a bit weirder than we feel comfortable with.

The easiest way to avoid the zombie arms syndrome is the accessory. Find yourself a clicker, or a bottle of water, or a mobile phone you pretend to use as a clicker, even a pen. Keep it in your hands at all times. One hander, two hander, you have something to fiddle with, and suddenly the stress goes away and you look like a natural.

As you get more comfortable, you’ll be able to play with your hands in a way that looks natural. Hold your fingers from one hand in the other in front of your chest, cross your fingers together, and accentuate what you talk about by making some movements. If you reach that level of comfort, you’re good, you can lose the clicker.

OO

Now you look fine. And you start talking. And. Then. You. Start. Losing. Your. Breath. This is a perfectly normal and common reaction. Your body feels fear, and reacts accordingly by hyperventilating, hence the O2 description of the title above. Your natural reaction is to get more and more air, so your body can prepare itself to flee or fight. Your natural instinct is to allow this to happen.

The counter-intuitive solution to fix this natural bug is to breath more slowly slowly. You have too much oxygen in your blood stream, you need to reduce that, and the only way is to get your breathing under control.

Remember the trick about having a bottle of water in your hands? It’s a double-whammy. When you start getting out of breath, leave a dramatic pause at the end of your sentence, and let the silence linger. As far as the audience is concerned, it’s part of the show. And for you, you get to open the bottle, breath all the way out, drink a couple of gulps, and breath back normally once, before picking up your discussion where you left it. This should allow you to recover from the chest pains described by [Todd][toddmoto], or any other form of anxiety attack.

The most powerful tool for managing stress however is the realisation that human beings came to hear you, a human being. You are not held to an unachievable standard: you’re just there to share what you said you would, nothing more, nothing less. And people are usually nice with it.

Know your content

People come to enjoy a show. You never see a TV program where people just stay silent as they fiddle with a remote control to show something to the public. Try not to do that, it’s a killer.

If you’re doing live coding demos, describe what you do and why you’re doing it when you are on the keyboard, even, and especially, when it all goes wrong. Explain: “Oh, we have an exception, of type blah, does anyone know why? Let’s just open the window for exception handling, which you can get through CTRL+ALT+E, and click catch on throw, and press F5 to re-run, this is going to allow us to know where the exception was actually raised, rather than where it was not caught.” It takes a bit of practice, but once you realise that talking nonsense and describing exactly what is visible on the screen is better than silence, it starts coming up naturally.

Speaking of demos, things go wrong. It’s OK. People are developers in your audience, they know stuff happens. Relax, try to fix it if you know what it is, otherwise revert back to a known state, git is your friend, or explain the expected outcome. Don’t stall on trying to fix a problem. I once had an MVC talk at DDD reading where my machine blue-screened at the beginning of the talk, and .net got corrupted, meaning I had no way of showing any code. I calmly explained the situation, opened notepad, wrote the code live from memory, and played the role of a hunan compiler: “in this instance, the code would result in X, trust me, for I am the compiler.”

To allow your slides and presentation to flow, discuss with yourself what you’re going to say. It’s ok to forget stuff, it’s ok to improvise. It’s not ok to have speaker notes that make you focus on your screen. No one came to see someone reading! Imagine the audience is just a bunch of people you’re hanging out with at the pub. Have a chat.

You may miss a thing or two you wanted to say, and that’s ok. It is better to flow the content and move on than to achieve all your key points while reading from notes. Leave cards at home. Design your slide so you can remember what you wanted to say based on what the slide is.

Some people advise rehearsing in front of a mirror, or even going through the slides. I’ve never done that, it does not work for me. I do have a lot of conversations with myself about each of the slides, and I hope that all this will be re-triggered whenever they show up on the screen.

Finally, when presenting, make sure you use a dual-screen and use the presenter mode. Knowing what slide comes next allows you to spit out the content for the current slide, and remind yourself of how to transition to the next slide.

Language is important

“You are live on UberConference 2016, please do not swear.” It took me a very long time to adapt my language to various audiences. Swearing is ok in controlled and measured fashions, in some audiences, and so are double-entendres. Be careful of not over-doing it, upsetting people, or allowing the jokes to overtake the content.

Once upon a time, Charles De Gaulle told the french Canadians, “Vive le Quebec libre!” When asked about it by his advisor Alain Peyrefitte, his explanation was that he got a bit excited. It’s natural in a high stress environment to want to push the boundary, and sometimes we do it so mindlessly that our words can go much further than we intended. Control yourself by going back to the basics I already described: what and why. And if you do it wrong, apologise, and move on.

Dress to impress

You don’t have to impress anyone else with your attire, the content should be king. But I dress to impress. It’s not about the audience, it’s about feeling good. Dress yourself in a way that you feel absolutely comfortable. It is your stage, it is your moment, and you need to think of nothing but your talk. Dress in a way that makes you feel good, empowered and comfortable. If you hate suits or dresses, don’t wear them!

Stereotypes of what is professional or not, what is commercial or not, can make us forget that our comfort is the main priority on a stage. If you’re comfortable, you will project comfort on the audience, and they will love you for that. After all, didn’t Don Box present a talk from a bath tub? Well, maybe do wear some clothes.

Experience over preparation

I’ll finish by agreeing with Todd. I don’t prepare much. I write my slides based on a story I want to tell. I go through many iterations, and eventually I settle on something that I feel excited enough to talk about. And that’s usually a few minutes before I’m due to present.

Don’t be fooled by the appearance of perfection some speakers can pretend. No amount of prep on your own can compete in any way with the overbearing experience of having presented.

Do your talk the best you can the first time. Present it at a user group. Take feedback from yourself, change the talk, present it again. Rinse, wash, repeat, until you fell it’s of acceptable quality.

Be it the nuggets of knowledge your provide, the jokes, the slides themselves, or the flow of the story, reading an audience when giving a talk is the most important feedback loop you have in getting your talk from horse meat to Irish beef.

Great speakers can pretend all they want, their good talks are due to having presented them countless times. That’s why they look like they’ve not prepared. The rest of us, we work on the slides until the last minute.

Ignore the audience, a little

The last bit is purely about stage presence. I can’t advise much on this, because I’ve not formalised it in my head yet. I’ll attempt a description of what I do.

I look at the audience as a whole, in a dazed fashion, until I find, in the first few minutes, the couple of faces that look friendly and reactive. I tend to hang on them for the rest of the talk. I call them anchors.

Every time you make a point, you ought to give that point to the audience. You want to show them that you care about them, and remind them that it’s all bout them.

To do that, I use my hands to focus the discussion, and I give my eye sight to an attendee. It’ll probably be one of the anchors I found. It’s good to talk to people that enjoy the talk, it fills me with confidence in my delivery, and it fills the whole audience with the warm feeling that everyone is getting my attention.

Looking back

It’s already a lot to take in, but those are the basic things I learnt over the years. They’re not for everyone, they’re just what works for me. Take one of each at a time, and try to find your own way to apply them. Don’t be a stranger, be yourself, learn and grow.