I just spent a few days in New York setting up a workshop to help minority students to get into development (soon more on that). I was lucky to be in Microsoft’s Reactor when Alex Sigaras, a research associate in computational biomedicine at Weill Cornell Medicine gave a talk about how HoloLens transforms healthcare research for the HoloLens Developer Group in New York.

@AlexSigaras is about to start his presentation on how #Hololens transform healthcare at the #Devs meet-up NYC https://t.co/eD8MLdmzrQ pic.twitter.com/FiypETVDt0

— Andrea Sboner (@asbonerw) 11 January 2017

I took the opportunity to talk to Alex for Decoded Chats about that. We also covered other topics such as sharing of information in healthcare. And how HoloLens despite being a high-end and rare device allows for collaboration of experts in all feld and not only developers.

If you prefer to have an audio version, you can download it here (MP3, 19MB)

Here are the questions we covered:

1. You just gave a talk at a HoloLens meetup about medical research. Who are you and what do you do with HoloLens?
2. What are the benefits of using the HoloLens as a visualisation tool in computational medicine compared to VR environments?
3. Is there a collbaboration benefit in augmented reality and mixed reality rather than virtual reality? Does it scale better in bigger groups?
4. Genomics is known to have to deal with huge amounts of data. Isn’t that an issue on a device that is self-contained like the HoloLens?
5. Most of the HoloLens demos you see are single person use. Your use case is pushing the collaborative part of the device. How does that work out?
6. What is the development stack you use? Did you find it hard to port to the device and to re-use code of other, VR, solutions you already had?
7. Do you also have some success stories where using HoloLens helped find a data correlation faster than any of the other ways you used before?
8. Is there any way for the audience here to collaborate in your research and help you further breaking down silos in medical research?

You can see the HoloLens work Alex and his team are working on in this tweet.

Our latest work on HoloLens with RoshalSophia ElementoLab engIPM. Source code coming soon on github. pic.twitter.com/tTtO8vWCPI

— Alex Sigaras (@AlexSigaras) 29 September 2016

The slides of his talk are on SlideShare and have a lot more information on the topic.

In addition to visiting Alex at work, I also got a special treat to have a demo of their other VR work, including The Cave, a room with 5 walls that are rear-projected screens allowing you to get detailed 3D views of MRI scans.

Here’s a very raw an unedited video of Vanessa Borcherding (@neezbeez) showing their research in VR and the insights it can give you.

Warning: unless you are also wearing 3D glasses, this video flickers a lot:

I left the hospital and research facility and had to take a long walk in Central Park. It is not every day you see things that you always considered science fiction and a faraway dream happen right now. I’m looking forward to working more with these people, even if I felt utterly lost and the dummy in the room. It is great to see that technology that on first glance looks great for gaming and entertainment can help experts of all walks of life to do important work to make people live longer.

I work remotely and with a team eight hours away from me. Many will be in the same boat, and often the problem with this is that your meetings are late at night your time, but early for the others. Furthermore, the other team meets in a room early in the morning. This either means that they are fresh and bushy tailed or annoyed after having been stuck in traffic. Many different moods and agendas at play here. To avoid this being a frustrating experience, here are seven tips any team in the same situation should follow to ensure that everyone involved gets the most out of the conference call:

• Be on time and stick to the duration – keep it professional – of course things go wrong, but there is no joy in being in a hotel room at 11pm listening to 6 people tell each other that others are still coming as they are “getting a quick coffee first”. It’s rude to waste people’s time. The meeting time should be information and chats that apply to all, regardless of location and time. You can of course add a social part before or after the meeting for the locals.
• Have a meeting agenda and stick to it – that way people who have a hard time being part of the meeting due to time difference can decline to come to the meeting and this may make it shorter
• Have the agenda editable to everyone available during the meeting – this way people can edit and note down things that have been said. This is beneficial as it acts as a script for those who couldn’t attend and it also means that you can ensure people remotely on the call are on the ball and not watching TV
• Introduce yourself when you speak and go close to the mic – for people dialing in, this is a feature of the conference call software, but when 10 people in a room speak, remote employees who dialed in have no no idea what’s going on.
• Avoid unnecessary sounds – as someone dialing in, mute your microphone. Nobody needs your coughing, coffee sipping, or – at worst – typing sounds – on the conference call. As someone in the room, don’t have conversations with others next to the microphone. Give the current presenters the stage they deserve.
• Have a chat window open – this allows people to post extra info or give updates when something goes wrong. It is frustrating to speak when nobody hears you and you can’t even tell them that it doesn’t work. A text chat next to the conf call hardly ever fails to work and is a good feedback mechanism
• Distribute presenter materials before the call – often presenting a slide deck or web product over Skype or others fails for various reasons or people dialing in are on a very bad connection. If they have the slide deck locally, they can watch it without blurs and delays

Using these tricks you end up with a call that results in a documented agenda you can send to those who couldn’t attend. You can also have an archive of all your conf calls for reference later on. Of course, you could just record the sessions, but it is much more annoying to listen to a recording and it may be tough to even download them for remote attendees on bad connections. By separating the social part of the meeting from the official one you still have the joy of meeting in the mornings without annoying the people who can’t be part of it.

Photo Credit: quinn.anya Flickr cc

Almost two years ago the G-Ro travel bag kickstarter did the rounds and all of us travelers pricked up our ears. It sounded revolutionary and a really cool bag that is a mix of carry-on and laptop bag. It’s unique physics and large wheels promise easy travel and the in-built charger for mobiles and laptops seems excellent.

As with many kickstarters, this took ages to, well, kick in and by the time mine arrived my address had already changed. They dealt with this easily though and this last trip I took the cool bag for its first spin.

Now, a caveat: if you use the bag the way it is intended, I am sure it performs amiably. The problem I find is that the use case shown in the videos isn’t really one that exists for an international traveler.

Let’s start with the great things about the G-Ro:

• It looks awesome. Proper Star Trek stuff going on there.
• It does feel a lot lighter when you roll it compared to other two wheeled rollers. The larger wheels and the higher axle point makes physically sense.
• It comes with a lot of bags for the interior to fold shirts and jackets and lots of clever features.
• Once you spend the time to go through the instructions on the kickstarter page you’ll find more and more clever bits in it.
• The handle is sturdy and the right length to pull. It is less of a danger to other travelers, as all in all the angle you use it on is steeper. You use less space walking. However, it still is worse than a four-wheeled bag you push on your side. People still manage to run into the G-Ro at airports.

Now, for a weekend trip with a few meetings an a conference, this thing surely is cool and does the job. However, on my 4 day trip with two laptops and a camera it turns out to be just not big enough and the laptop bag is measured only for one laptop and not even a sensible space for the chargers.

Here are the things that miffed me about the G-Ro:

• Whilst advertising that it is the correct size for every airline to be a carry-on, the G-Ro is big and there are no straps to make it thinner. This is what I like about my The North Face Overhead Carry on Bag. This means that on an Airbus in Business Class, the G-Ro is a tight fit, both in height and length.
  As most airlines ask you to put your coats on your bag, this is a no-go.
• The easy access bag on the front for your liquids and gels is flat and big, but the problem with liquids and deodorant/perfume bottles is that they are bulkier and less wide than that. This easy-access bag would be much better as another laptop/tablet holder. With your liquids in that bag, the G-Ro looks bulky and you’re sure to bump against the top of the overhead compartment with your liquids. Basically there is a good chance for accidental spillage. A bag on the side or a wider one on the back would make more sense.
• The bag in the back in between the handle bars is supposed to be for your wallet and passport, and thus works as an advertisement for pick-pockets. I used it for the chargers of my laptops instead, and that’s actually pretty convenient.
• The G-Ro is very clever in the way you can put a lot of cables and hardware into a very tight space. This is convenient, but also ensures that every time the bag is X-Rayed at the airport, it is taken out and officers ask you to remove things. Instead of keeping cables, iPods and chargers in the bags they should go, it would be better to have a removable pouch for them. I will use a Cable Organiser to avoid this now.
• One thing that is not really a problem but freaked me out is that the G-Ro is always slightly tilted and I am always wondering if it will fall over. It won’t, and what is pretty cool is that you can fully open the front bag without it falling over. But it is something to get used to.
• Now, I might have put too much in for a four day trip, but here is the main issue with the G-Ro. For its size it is ridiculously heavy – you know, like the first two Black Sabbath albums heavy. With its big wheels it feels great to pull the bag, but once you get to some stairs, you get a rude awakening. No, you can’t roll it down most stairs, as it would bounce and as with all two-wheel bags you have the issue of a slight angle going down a step making the bag fishtail. The heaviness of the bag is exacerbated by the uselessness of the handle on the side, which doesn’t pull out at all and thus for my fat fingers is a trap and great to remove fingernails rather than a way to carry the bag or pull it out of the overhead compartment.
  

All in all, I am not punishing myself for backing this product, but it is only useful for a certain use case. In essence, it is a glorified backpack or laptop bag, but not a full travel companion. I’m looking forward to using it for weekend business trips that last two days, as it will force me not to buy things. But with all the hype and the plethora of useful features that the web site and the videos promise us, I found it underwhelming, especially for this price.

Today on the Decoded Blog I published the first ever Decoded Chat I recorded, where I grilled Paul Baukaus in detail about AMP.

This is an hour long Skype call and different to the newer ones – I was still finding the format :). There are quite a few changes that happened to AMP since then and soon there will be an AMP Summit to look forward to. All in all, I do hope though that this will give you some insight into what AMP is and what it could be if the focus were to go away from “Google only” with it.

These are the questions we covered:

1. What is AMP to you?
2. The main focus of AMP seems to be mobile, is that fair to say?
3. Was AMP an answer to Facebooks’ and Apple’s news formats? Does it rely on Google technology and – if so – will it be open to other providers?
4. It seems that the cache infrastructure of AMP is big and expensive. How can we ensure it will not just go away as an open system as many other open APIs vanished?
5. Do large corporations have a problem finding contributors to open source projects? Are they too intimidating?
6. Is there a historical issue of large corporations re-inventing open source solutions to “production quality code”? Is this changing?
7. Whilst it is easy to get an AMP version of your site with plugins to CMS, some of the content relies on JavaScript. Will this change?
8. AMP isn’t forgiving. One mistake in the markup and the page won’t show up. Isn’t that XHTML reinvented – which we agreed was a mistake.
9. AMP seems to be RSS based on best practices in mobile performance. How do we prevent publishers to exclusively create AMP content instead of fixing their broken and slow main sites?
10. It seems to me that AMP is a solution focused on CMS providers. Is that fair, and how do we reach those to allow people to create AMP without needing to code?
11. A lot of “best practice” content shown at specialist events seems to be created for those. How can we tell others about this?
12. AMP seems to be designed to be limiting. For example, images need a height and width, right?
13. In terms of responsive design, does the AMP cache create differently sized versions of my images?
14. Are most of the benefits of AMP limited to Chrome on Android or does it have benefits for other browsers, too?
15. Do the polyfills needed for other browsers slow down AMP?
16. How backwards compatible is AMP?
17. One big worry about publishing in AMP is that people are afraid of being fully dependent on Google. Is that so?
18. Are there any limitations to meta information in AMP pages? Can I add – for example – Twitter specific meta information?
19. Do AMP compatible devices automatically load that version and – if not – can I force that?
20. How can I invalidate the AMP cache? How can I quickly remove content that is wrong or dangerous?
21. Right now you can’t use third party JavaScript in an AMP page. Are you considering white-listing commonly used libraries?
22. It seems AMP is catered to documents, while most people talk about making everything an App. Is this separation really needed?
23. What’s the sandbox of AMP and how is this now extended to the larger web as a standard proposal?

There is a consensus among all browser makers and lovers of the web: the current state of the web is a mess. The average web page is 2.4 megabyte big and has over 200 requests.

We spend more time waiting for trackers and ads to load than we spend reading content. Our high-powered computers and phones, our excellent mobile devices choke on megabytes of JavaScript and CSS. Code that often isn’t needed in the environments it currently gets delivered to. Code that fixes issues of the past that aren’t a problem anymore these days.

Our reaction to this is a lot of times an assumption that people use libraries and frameworks because they don’t know better. Or that people use them to solve an issue they have that we don’t — like having to support legacy environments.

I’m getting more and more the impression that we are wrong in our approach. This is not about telling people that “you don’t need to use a framework” or that “using XYZ is considered harmful”. It isn’t even about “if you do this now, it will be a maintenance nightmare later”. These are our solutions to our problems.

We’ve done this. Over and over again.

Information is plentiful and tools aren’t a problem

We try to do our best to battle this. We make our browsers evergreen and even accessible as headless versions for automatic testing. We create tools to show you without a doubt what’s wrong about a certain web product. We have simulators that show you how long it takes for your product to become available and responsive to interaction. We allow you to simulate mobile devices on your desktop machine and get a glimpse of what your product will look like for your end users.

We create toolchains that undo the worst offenses when it comes to performance. We concatenate and minify scripts and CSS, we automatically optimise images and we flag up issues in a build process before they go live.

We give talks and record training videos on how to build a great, responsive product using modern browsers whilst supporting old browsers. We release all of this for free and openly available — even as handy collections and checklists.

And yet, the web is a mess. And I’m not even talking about products that bloat because of maintenance issues or age. Brand new, celebrated and beautiful products get even the basics of performance wrong. Why?

One reason for bloat — a lack of suffering the same problems

One of the biggest reasons is that developers in general don’t suffer the same issues end users do. We check our products on fast, well equipped devices on fast and steady connections. We use ad blockers. We don’t test our products on a mobile device with a flaky connection. We don’t test them on outdated setups that may well still be in use out there. We don’t even test them on other operating systems than ours. If it isn’t broken on our machine, it is good enough to release.

This is not malice on our behalf, it is at the worst indifference to other people’s needs. But most likely something else is the real problem.

The main reason for bloat

I think it is much more likely that the code quality of the end product and its performance isn’t even on the radar of many companies. We live in a market that moves at breakneck speed. Being first to market is paramount.

Companies that are funded to create hype and get millions of users posting random stuff, liking and adding emoji or commenting and sharing don’t care if they send a lot of unused JavaScript down the wire. They want to be the first to roll out a new feature that also can be turned off a month later when people don’t want it any more. They want to be the first to have the feature or be fast to add it when a competitor has success with it.

A lot of our messaging is the total opposite of that. With good reason. This is not a healthy way to work, this is not how you build a quality product. This is how you build an un-maintainable mess full of security holes and bloat. But this is how you make investors and prospective buyers happy.

We live in a market of hype and quick turnaround and we preach about longevity and quality thinking that takes time and effort and will yield results in the long run. We are right, we have proven over and over that we are, but the business model of our quick success poster child web companies is utterly and totally not about that.

I am not saying that this is good. At all. This constant push for innovation for the sake of showing something new and getting people even more addicted to using our products is killing the web. And it is killing our community and leads to an overly competitive work environment that favours 10x developers who have time and the drive to work 20 hours a day for a few months on a product that is destined to be scrapped a few weeks after the pivot.

Our job is to battle this.

Our job is to shine a bright light on all the bullshit cinderella stories of the unknown startup that made millions in a month by moving fast and breaking things.

Our job is to push back as developers when project managers want us to deliver fast and fix later — that never happens.

Our job is to give sensible estimates as to what we can deliver in a certain time and be proud of what we delivered.

And our job is to work closely with library and framework creators to ensure that products based on things that promise “deliver more by writing less” result in quality code instead of overly generic bloat.

People don’t bloat products because they don’t know better. They do it because they want to be seen as incredibly productive and faster than others. And that comes at a cost that is not immediately evident and seems not important in comparison.

The biggest problem we need to solve is that we celebrate re-inventing our way of working every few months. Instead of dealing with our jobs asking us to deliver too much in not enough time we started falling into the same trap. We want to be seen using the newest and coolest and follow patterns and ways of working of the fast companies out there. Quality and working with the platform isn’t sexy. Inventing new things and discarding them quickly is.

No, I am not against innovating and I’d be the last to pretend that the web stack is perfect. But I am also tired of seeing talented developers being burned out. We have a 1–2 year average retention span of developers in companies. This is not sustainable. This is not how we can have a career. This is not how we can become more diverse. The ugly brogrammer is only in part our own biases and faults. It is a result of an unhealthy work environment based on “release fast and break things”. We broke a lot. Let’s try to fix it by fixing what people use, not telling them what they should be using.