For those of you who missed it, there’s something fun happening in London this weekend- and I’m going to be there. Yes, it’s the AEC Hackathon! To make life a bit more exciting (and to allow me to get all the dull things I’d usually do on a weekend out the way), I’ve decided to make a repeat of my last Construct//Disrupt attempt and blog live from the event.

So once again, let me invite you to check-out Being Brunel Live!

Being Brunel: Live

As the event is a two and half days long, expect updates to be a touch more periodic than the steady stream I achieved last time. As always, feel free to drop me a line (perhaps on Twitter) with any questions, comments or suggestions and I’ll try and answer, respond or action them!

The post AEC Hackathon 3.3 appeared first on Being Brunel.

In the future everything will be 3D printed. Or so we are led to believe. Like most of the science fiction-esq technologies I grew up with: robots, hoverboards, traffic lights that play music to you– 3D printing is slowly becoming a reality. So we might as well make an attempt to understand it…

I’m going to kick off this series by stating the obvious; however 3D printing has a more specific definition then you might expect. It’s the process of digitally driving the creation of a physical three-dimensional model by “printing” a succession of layers on top of one and another to build depth.

It’s a definition that’s analogous with the way a 2D digital printer works; line upon line of pixels, each one after the other on a page. This analogy extends a little further; as it excludes techniques that achieve similar results like screen printing and stenciling.

Similarly 3D printing does not include CNC machines and robot assembly, which although digitally driven that effectively use tools to hune objects. This is why the common term “3D printing”” is more technically known as Additive Manufacturing; the process of manufacturing by continuously adding (not official definition)!

I have come to think of additive manufacturing as the finite element method of creating.

Its strength is that it is generic: it might not always be the best way to do something, but it’s the only way to do anything. You can design any structure using FEA; yes there might be”quicker” ways- simple beam theory and the like. And that’s the same opportunity AM offers; a “general solution” to the making problem.

I’m going to talk about the different printing methods with their advantages and disadvantages, and take a look at the current attempts to bring the fledging technology to construction in later posts. For now I just want to dwell on some of the opportunities 3D Printing offers civil engineering.

The most outlandish is the dream that well simply print our future buildings and infrastructure out in there future. Whilst that sounds a little ambitious, even to me; it outlines the possibilities on offer. The most obvious in that example is the robotised workforce; effectively making our site safer and construction much more controllable and predictable.

3D printing allows you to create advanced geometries with a high precision. This gets architects excited as it opens up previously impossible options to them. However for engineers this means no more deliveries (print components on site), much smaller tolerances less faffing on site- imagine printing rebar cages!

Finally by definition AM has little to no waste; every piece of material used must end up in the structure- or be later removed by another process (i.e. temporary works). For an industry that regularly tops the wastage charts, this is not something to be sneered at.

Of course there are some challenges, and I’ll get round to those as well…

The post 3D Printing: An Introduction appeared first on Being Brunel.

Last week I talked at length about the wonderful world of the Web API, but completely failed to provide any details of how you can start playing with them. Well today we’re going to do some engineering with twitter using their RESTful API.

Interacting with Web APIs is normally done programmatically, and so varies from language to language. However, once you’ve got the process down it’s just a matter of implementation. To ease the learning curve, however, we’re going to be using Twitter’s Developer Console; thus requiring you to do absolutely no coding at all:

Twitter Developer Console

OAuth

As Microsoft’s Tay learnt the hard way– if you go around trusting everybody you meet on the internet, you’re going to get shutdown. This means that most ‘open’ API’s on the internet need you to authenticate; provide an identity that you can be traced and trusted against. OAuth is one of the most common ways of authenticating yourself to a Web API. In fact, you’ve probably used OAuth without knowing it!

As a ‘good-enough’ analogy, OAuth is like your site safety card. You get yourself tested by, and give all your personal details to, the issuing authority, and then you get given a card. When you visit a site the inspector rings up the issuer and verifies the card, and then hands you a visitor pass for that day and that site. In this case the card is your login details, the issuing authority is often someone like Twiter, Google, GitHub, etc., the ‘site’ is the api and the visitor pass is called an access token.

So, before we can started you need to authenticate in the Twitter Developer Console. At the top centre is an Authentication area, initially saying No Auth. Drop this down and select OAuth 1.1, at which point you’ll be asked to login to Twitter. Congratulations, you’ve now got your access token (although this interface simplifies things and just stores it behind the scene.)

Headers

So let’s make a request. To save you learning the whole Twitter API you can expand the dark gray sidebar on the left on the console, which will then list all the actions available to you. We’re going to search tweets, and in Twitter’s RESTful API that means GET‘ing /search/tweets.json (I’ll touch on what the .json means later).

To be helpful the console will now expand to ask you for the parameters needed to complete the query string. For this example we’ll go searching up the #EngineeringIsArt tag, so type #EngineeringIsArt into the q parameter and press Send.

The Console then shows you two (overly) technical looking outputs. On the left is the Request that you made, and on the right is the Response the Twitter server returned. We’re going to focus on the response, which is formed of two parts- the header (first bit) and the data (which starts at the {).

Headers are used by HTTP to transfer protocol level information. There’s a lot of information in the response header, with everything from the time the data was put together for you to the cookies that it wants the browser to set. Only two bits of this are all that interesting for us: the status and the content-type.

The status is a number indicating how things went. There are a good few codes, however the most useful to know are:

• 200: OK
• 400: Bad Request (normally because you didn’t authenticate)
• 404: Not Found
• 500: Server Error

The content-type tells you what ‘format’ the content you’ve be returned is in. In this case you’ve being given some json, but it could be a jpeg image or something even more exciting!

JSON

A few years back the web was a place of many languages, however these days you’ll find that most Web APIs will return data to you in something called JSON (JavaScript Object Notation). Sometimes you might also see an option for XML, but by and large we all talk JSON.

The data in the response is in JSON:

"statuses": [
  {
    "created_at": "Sun May 22 13:16:41 +0000 2016",
    "id": 734372412578533400,
    "id_str": "734372412578533376",
    "text": "I call this 'Fenland Footbridge'. Because that's what it is... #EngineeringIsArt https://t.co/BE1qPcGBhR",
    "truncated": false,
    "entities": {
      "hashtags": [
        {
          "text": "EngineeringIsArt",
          "indices": [
            63,
            80
          ]

Hopefully you can make out some of the data already, but it’ll help if I tell you that JSON works like this:

• "key": "value"
• { collection of keys and values }
• [ list of values/collections ]

So in the data above we have a key statuses that contains a list of Twitter statuses (tweets). The components of each status is collected in { } brackets, so the first status was created at Sun May 22 13:16:41 +0000 2016 with the text I call this 'Fenland Footbridge'. Because that's what it is... #EngineeringIsArt https://t.co/BE1qPcGBhR.

Return Post

To finish off let’s use the Twitter Developer’s Console to send me a message.

1. Making sure that your Authentication is set to OAuth so that twitter trusts you to send a message…
2. Expand the API selector on the left side and Direct Message > direct_messages/new.json
3. Enter the parameters:
   1. text: Cheers for the tutorial Tom!
   2. screen_name: beingbrunel
   3. user_id: leave blank
4. Press Send

Looking at the Request you’ll see you’ll see you POST‘ed to (twitter)/1.1/direct_messages/new.json?text=Cheers%20for%20the%20tutorial%20Tom!&screen_name=beingbrunel (the funny %‘s are to do with the way punctuation is sent in HTTP).

In the response you’ll see 200 in the header; you successfully sent me a message (Thanks!). But you’ll also see a bit lump of data, giving the ID of the message, the text, and some information about yourself in the sender` collection. This ‘echoing what you sent’ approach is fairly common in WebAPIs as it lets you verify that what you asked to happen, happened.

And that’s most of the more difficult bits of working with a Web API. In the final post of this series I’m going to hopefully get you started on some of the APIs that have some more practical use to you civil engineers out there.

The post Engineering the Twitter API appeared first on Being Brunel.

I‘m sure I don’t have to tell you that the internet is awesome. Or indeed that it’s everywhere. But its ubiquitousness might surprise you. Many devices and applications talk “internet” in their APIs (application programming interfaces), which is becoming a sort of lingua franca of tech, and knowing how it works will help you leverage more and more sources in civil engineering.

The internet boils down to one protocol: HTTP. And for all the average user needs to know, it’s a language of five verbs. You can GET something, POST something new, PUT an updated version of something, DELETE something unwanted and PATCH something with a few changes.

Congratulations, you now speak HTTP. In fact, when you browsed to this page you actually GET it. And when you fill your email address to sign up for updates you POST it to me. When you fix that badly spelt YouTube comment you PUT the changed version and when you delete that drunk photo on Facebook you DELETE it. (PATCH is, alas, not all that common unless you’re working on big documents.)

Just knowing the HTTP verbs will get you pretty far. But as an English teacher will tell you, verbs just aren’t enough. You need need an object to your sentence; something to do you verb on.

Years ago during the great API wars there were many competing standards, but these days pretty much every web API you interact with will be RESTful.

REST is a convention. It sits on top of the HTTP verbs to make it stupidly easy to express what you want. The idea is simple, everything you GET, POST, etc. to should be in the form /things/identifier. So, in a typical RESTful pattern:

• GET /things/ – Gets all the things
• GET /things/1 – Gets the first thing
• GET /things/1/bits/2 – Gets the second bit of the first thing
• POST /things/ – Adds a new thing
• PUT /things/1 – Updates the first thing with some new data
• DELETE/things/1 – Destroys the first thing!

There’s one more thing you need to be versed in before you can classify yourself as a Web Genius, and that’s how to ask a question. By convention, questions (or API query strings as people pretending to be technical call them) are asked using a ?, followed by a & separated series of options=values. So:

• GET /things/?colour=red – Gets all the red things

Unfortunately there’s no REST-like discoverability for what options you can use; you’ll have to just check the documentation or see what you can work out by looking at the query strings of others. Wrapping up all we’ve learned so far:

GET https://twitter.com/hashtag/engineeringisart?f=images

• GET‘s
• From https://twitter.com
• The /hashtag/engineeringisart
• Displaying only the ?f=images

And that’s the basics of how pretty much every internet enabled application speaks. In later posts I’ll go through some of the nuances like authentication and data formats, as well as talking about how you can use this new found knowledge to leverage the web.

The post Web APIs: An Engineering Introduction appeared first on Being Brunel.

What are you doing Thursday evening (that’s 19th of May 2016, for the archives)? Why not grow yourself a hipster beard [optional] and pop on over to trendy Shoreditch to find out what all this “proptech” excitement is about?

For those of you who haven’t heard about it, Construct//Disrupt is a gathering for all the innovators in construction; giving some of the coolest start-ups in our industry a platform to showcase what their about. I went to the first one and thoroughly enjoyed it. For the third iteration BaseStone have brought together some of the leading names in proptech to share their vision of the future:

• WiredScore – Find the Best Connected buildings In London
• Converge – Wireless Sensor Networks for the connected site
• Spacehop – Book home office space whenever you need it
• BaseStone – Capture, manage and share construction data
• Resolution Property – Real estate investment
• Savills Tech – Real estate service provider
• PropertyScape – Virtual reality for property
• Elegant Embellishments – Research and Design-Manufacturing studio

There’s beer and pizza too!

RSVP for Free!

The post Construct//Disrupt 3: Proptech appeared first on Being Brunel.

We’ve all been there; it’s practically a rite of passage for a growing engineer- that arch needs inspecting, that detail needs checking, the designer has (as usual) asked you to do something impossible and you’ve made a genius hack-and-slash at three in the morning. It’s raining, your loving set of (outdated, it will later transpire) drawings are pretty much pulp, and your handwriting looks like you’re giving ambidexterity a go.

When you return to the office you waste twice the time of the inspection making sense of the inexplicably out-of-order photos and deciphering your handwriting; presenting it in a fashion that can be read by the non-caffeine crazed. The rest of the day passes exchanging mark-ups back-and-forth; tethered to your e-mail when you should be doing some real engineering. And you begin to think, if only there was a better way…

Anyone who read my Construct/Disrupt summary may have noticed an omission; I didn’t actually talk about the hosts. This was in part because I’ve had “write something about Basestone” down on my long list since the very first Construct/Disrupt, but also in emulation of their admirable decision not to use it as a platform to pontificate about themselves.

A few weeks after, however, I got an email from one of the team saying thanks for the post, would I like to come for a drink sometime. I decided to push my luck and ask for an interview with the founder, Alex Siljanovski, and I actually got one. I’m not exactly the NCE, so it’s fantastic to see a company that cares enough about the construction community to give the likes of me some time.

A few days later I was in a bar in Mile End conducting what was probably the world’s least professional interview- but it was great to meet a team who were as passionate about the need to drive change in the industry as myself. So even if you don’t like the idea of BaseStone (I still haven’t negotiated any commission; [Ed. OK- they did by me half a pint of coke, but I’m not that much of a cheap date]), I think you should be excited about what it represents and give it a chance.

BaseStone?

So what is this BaseStone? Well; it’s an online issue tracker for drawings. Que? Let’s go back to our career-defining moment- why, in Brunel’s name, am I expending more of my time administering a task than doing it? In the age where I carry enough tech around with me to do a FE analysis in the post office queue, I should have been marking up the drawings, attaching photos and raising and assigning issues while I was there.

In the world of BaseStone, I’m not getting closer to nature armed only with mushy paper; you’ve got a tablet with you, and you use their system to open the latest drawings, annotate them with the issues and distribute them in real-time (internet depending) to the rest of the team, who can use the web app to respond immediately (office hours depending). It’s a simple innovation; hell- even Royal Mail identified that getting you to sign for delivery on paper was stupidly inefficient.

In The Wild

It’s relatively easy to think of a product you haven’t heard of before as being new. However it turns out BaseStone is fairly battle worn these days; currently being used worldwide on everything from house extensions to major civil sites. So if you want to know what it’s like under stress, go ask someone from CSJV working on Paddington CrossRail and Bond Street.

Anyone who has ever attempted to make a suggestion to the likes of AutoDesk/Bentley will probably sympathise with the notion of filling a black hole with meringues. Like a lot of web apps, however, BaseStone uses a tight feedback/improvement loop- in an industry where innovation is king, they want to know what their customers want. And while they didn’t manage a reply at 9pm on Sunday- there was a response in my mailbox by 8am Monday.

So what have they learnt, and what are new functionality are they targeting? Well the next big feature will a more trackable workflow; helping to define the process between raising an issue and getting it resolved- especially across multiple stakeholders. Of course, the challenge here is to keep it simple and intuitive enough to be accessible within the larger workflow that projects are delivered in. Import/export links to other software (for example Bentley Enterprise Bridge) are also being developed.

Playing With Yourself

Before you all scoff at the notion of your company buying you an iPad [Ed. I did ask; an Android version is coming, for all of those who are allergic to Apples]; I would ask you, and more importantly, them to value your time. Even at graduate level, getting a day of your time back in chargeable hours should easily pay for one; without mentioning the reduced resource pressure.

But even if you don’t manage to get some interest off the bat; you can do it on your own for free. Of course, you won’t realise the full potential that using the same platform across all project stakeholders can offer- but you will close in on your own duplications, and maybe even ease your own issue management. And if that doesn’t convince anyone, you can at least build yourself a reputation for being 65% (apparently) more efficient than everyone else- which will help you get that new job in an engineering firm that is making a bit of an effort to move with the times.

Now For The ScienceTech Bit

What sort of engineer would I be if I didn’t pull things apart to see how they work? Anyway, from a quick poke around it seems that BaseStone is running a Backbone frontend with a Django/Python backend (and perhaps some Node thrown in for good measure). All of these are fairly mature pieces of tech (as far as that can be applied to the fast-paced world of web development) that I’ve used and trust; and who would argue with me!

It’s also cloud hosted/distributed, which means that should the world and its wife read my article and decide to give it a go; it should scale pretty well. I did ask about self-hosting, and while obviously the preference is their system, they are supporting projects where companies want to get the data on their own servers; and had considered, although yet to be asked, allowing the app to be cloned to run entirely privately (for high security projects like nuclear and my secret volcano base) .

As it forms a part of my job, and frames a key concern of mine about the amount of data we’re lovingly pouring into closed formats in the name of BIM, BaseStone won my favour by exposing a self describing web API. And while that may not mean a lot to many of you; it means that you can easily drive it programmatically. This is important.

Just to prove the point, I wrote the following example program without even mentioning it to their developers. [Ed. I’ve got an article or two planned about interoperability, where I’ll explain how I did this]. And while their API isn’t fully open for application developers, yet, I did manage to confirm the intention, during the interview, to allow integrations, etc. to help place BaseStone more efficiently in the workflow.

BaseStone “Issue Tracker” App Example

So that’s BaseStone; but what got me the most excited was the chance to sit down with someone who has literally set out and launched something to help change the construction industry. To keep things clean, I’ve separated that half of the interview into a second part; so watch this space for a look into what it means to become a construction/tech entrepreneur.

The post An Evening With BaseStone appeared first on Being Brunel.

Last week I got an unexpected e-mail (actually; I got a few, but that’s a story for another time). It was to introduce me to the BIM2050 group; the CIC’s tendrils into the future- looking to establish what construction (note the three letter drop) will look like in 35 years time, and what we have to do to get there. It turned out they were wondering who was responsible for filling the internet with badly spelt engineering rants…

Because I’m a well balanced individual I responded with a putting-the-world-to-rights tirade of suggestions for what the industry would be like if/when I become undisputed emperor of all engineering. It makes a nice continuation of my old NCE competition entry, and so I thought I’d showcase my continuing frustrations with the industry as my experience of it grows:

Support for disruptive technologies/start-ups in construction

Look at the wholesale change events like Disrupt have brought technology…

Fast track the inclusion of new materials/processes into our regulations

FRP is nearly 75 years old now, and it’s still considered a “new” material…

Democratize the design process

Let the community take ownership over its infrastructure again; surely that’s Sustainability 101.

Rapidly improve our design by building in monitoring to inform future design practices

It’s amazing how many conservative approximate approaches we take as being accurate. Cheap monitoring is already available to show us the truth behind our long-held assumptions…

Reworking our contracts/tenders for collaboration

The do and sue model needs to go; engineers need to start being incentivised to collaborate.

Improve access to innovations

Our industry is full of innovators, but they don’t have anywhere to share or profit from their successes, so they just fall by the wayside.

Import management ideals from other industries

Why aren’t we attempting to be Agile or LEAN? There’s a lot to learn from industries delivering similar mega projects with challenging specifications; let’s give it a go!

Push for parametric pre-modular structures

It’s madness that we still design the same bridges over and over again; let’s standardise our infrastructure like every other discipline.

Establish spaces for engineers to freely mix and safely share new ideas

Maybe the ICE was more effective when it was just a bunch of enthusiastic engineers sitting in a coffee shop?

And if we’re still using BIM in 2050…

I’ll be incredibly disappointed- we should be using whatever is born of the lessons of BIM.

The CIC is actually linked to the government; so if I have faith in anyone to influence the policy we need to help affect change in the industry- it’s them. So watch this space; at the very least I’ll be following their progress with interest…

The post Introducing: BIM2050 appeared first on Being Brunel.

A good few weeks ago I suspended my disbelief and took the opportunity to pretend civil engineering is just as full of young and trendy start-ups as those cool cats at Silicone Valley. BaseStone’s second Construct/Disrupt definitely set the scene; beer, pizza, checked shirts- even the engineers who had turned up made an effort look a little trendy. But the stars of the show were the new technologies on display; and that’s what I want to draw your attention to today.

Bill Clee (Asset Mapping)

Winning me over with the quip: “Standards are a bit like toothbrushes – everyone has one and no one wants to use anybody else’s.” Clee introduced us to Asset Mapping’s technique of doing away with the archaic, propriety and often incompatible interfaces that link our building services and using a combination of open standards and cheap sensors to monitor a company’s physical assets. This internet of things means that businesses can know the state of their estates and plan accordingly.

Jozef Dobos (3D Repo)

As something between a software and structural engineer; I find myself constantly at odds with the way both industries manage data. Anyone who has seen the wonders of GitHub will understand; and clearly Dobos has- because 3D Repo is git for drawings. Open source (e.g. free to use and collaborate to improve); it allows you to view, monitor and merge changes to BIM models. I can only hope that the oddities of “common formats” are straightened out so that this can be the de facto standard and we can all get on with our lives.

Fred Mills (The B1M)

I like the B1M. It’s the ultimate resource to get you enthusiastic about BIM; with weekly videos from some of the current through leaders in the business. But more than that, it was good to hear Mills’ views on the need for our industry to adapt- “organisations can no longer hoard their information; we are judged by out contribution”; as designers we need to focus on our ability to innovate- not just hoard our old innovations.

James Bowles (Freeform 3D)

Just as the industry is coming to the terms with the third dimension, Bowles has taken to talking about the forth (and the last of the real dimensions that BIM inhabits). Toting that projects undertaking 4D modelling end up being executed faster (something I dearly want to believe; but take it with a pinch of salt); he predicts that in the future we will model full cities in 4D to see how the projects interact and better manage the interfaces.

Freddie Talberg (PIE Mapping)

I cycle in London. So when Tablerg announced that trucks turning left kill cyclists, I vowed to avoid left turning trucks forever. Luckily PIE Mapping is working to make my life easier by preventing trucks turning left forever; well- almost. By combining their mapping and routing knowledge with live data across London they are working with construction (and logistics) companies to ensure that heavy vehicles are routed across the city in such a way that they do avoid this dangerous manoeuvre at cyclist heavy junctions!

Oluwaseyi Sosanya (Gravity Sketch)

Engineers sketch; in fact, I was once congratulated in an interview for reaching for a pen a paper to sketch with. Anyone who has had to convert a collection of dodgy hand-sketches into a beautiful 3D model will know, however, that sketching well is an art- and not one widely practised. Sosanya has the answer- just sketch in 3D. Gravity sketch is an up and coming app that allows you to form a mobile plane with a tablet; adding the third dimension to your sketch-pad. You can even combine it with VR technology to allow you to visualise and manipulate the sketches of others.

Henry Stuart (Visualise)

What isn’t construction doing that every other industry is? Well, I could write a list; but for Stuart, it’s forming Virtual Reality experiences. We deliver schemes worth billions to clients who have seen little more than an architectural rendering (on a summers day, with a suspiciously diverse crowd hanging about). Imagine how much better we could realise their expectations with a full VR experience; allow them to meander across the bridge that isn’t there- or sit down in the tiny luxury apartment to be. More than that, we could be running full virtual executions of complex designs to predict problems before we get to them on a Christmas possession…

So there you have it; it might seem like the industry is just plodding along compared to our technological counterparts- but there’s still an undercurrent of disruption to help shake things up. Here’s to whatever these hopeful startups become!

The post Disrupting Construction appeared first on Being Brunel.