ganonm

Ai Build | London, UK | Backend/Frontend/Fullstack Software Engineers, Data Scientists| Full-time | ONSITE

http://ai-build.com/technology.html

We are an early-stage startup developing large-scale, autonomous 3D printing technology to provide the factory of the future to our customers. We utilise industrial 6-axis robots combined with plastic extruders to print large scale structures and objects (often at a scale of meters). Our current focus is on development of the web platform and our proprietary toolpath algorithms.

Tech stack: Dropwizard (Java 8, Kotlin), PostgreSQL, React, Redux, NGINX, Docker, Terraform

We are hiring for several roles

- Frontend (required: 1+ years experience with React, CSS & HTML. Beneficial: experience with 3D programming e.g. ThreeJS, familiarity with REST APIs)

- Backend (required: 1+ years experience with a JVM server framework, REST, Strong grasp of computer science fundamentals. Beneficial: mathematical background/strong knowledge of data structures/algorithms)

- Data Science (required: 1+ years experience implementing modern machine learning techniques in a professional or academic capacity, familiarity with software engineering practices e.g. version control and application architecture. Beneficial: PhD in closely related area, prior experience working as a software engineer and/or a computer science degree)

If you are interested, please contact us at jobs@ai-build.com

Please do not contact us if you are a recruiter

Ai Build | London, UK | Backend/Frontend/Fullstack Software Engineers, Data Scientists| Full-time | ONSITE http://ai-build.com/technology.html

We are an early-stage startup developing large-scale, autonomous 3D printing technology to provide the factory of the future to our customers. We utilise industrial 6-axis robots combined with plastic extruders to print large scale structures and objects (often at a scale of meters). Our current focus is on development of the web platform that is used for managing the printers and generating toolpaths. We are also constantly investing effort into developing our core printing algorithms further.

Tech stack: Dropwizard (Java 8, Kotlin), PostgreSQL, React, Redux, NGINX, Docker, Terraform

We are hiring for several roles

- Frontend (required: 1+ years experience with React, CSS & HTML. Beneficial: experience with 3D programming e.g. ThreeJS, familiarity with REST APIs)

- Backend (required: 1+ years experience with a JVM server framework, REST, Strong grasp of computer science fundamentals. Beneficial: mathematical background/strong knowledge of data structures/algorithms)

- Data Science (required: 1+ years experience implementing modern machine learning techniques in a professional or academic capacity, familiarity with software engineering practices e.g. version control and application architecture. Beneficial: PhD in closely related area, prior experience working as a software engineer and/or a computer science degree)

You will be joining at an early stage and thus will have a large say in how we progress our technology. We are hoping to find fellow engineers who care about code quality and modern software engineering best practices. We aren't into micro-managing and prefer people who have the ability to work independently with minimal guidance.

If you are interested, please contact us at jobs@ai-build.com

I work mostly solo on the web platform which is in Kotlin. It uses our 3D printing algorithms which are written in Java (which I also work on). Some weeks I'm writing mostly Java, others Kotlin.

We're looking for engineers in London incidentally, if anyone is interested. See my post in this month's who's hiring.

I had assumed you weren't a fan, apologies for jumping to conclusions. The copyright concerns are valid - I've only followed the whole Oracle vs. Google litigation from a distance. I'm hoping the little guys like us won't be affected.

I am at an early stage startup which is using Java (and Kotlin) on the server-side. There are various reasons for this, most of them pragmatic, but also some technical ones. Pragmatic reasons:

- Many engineers know Java to at least an intermediate level, so they can be productive quicker (and hiring is easier)

- We had some existing libraries written in Java, so integrating them with the web platform was much easier if we went down the JVM route

- Java is the language most familiar to members of the startup (including me, although I also have experience in RoR, Kotlin, ObjectiveC and JavaScript)

Technical:

- Java is generally very performant and running on the JVM means we don't generally have to worry about platform specific issues (there are well known exceptions of course e.g. file path issues)

- The language itself is at a reasonable level of abstraction. It is strongly typed and IMO, writing a non-trivial backend in a dynamically typed language is a sub-optimal choice. It has a huge ecosystem of robust, battle tested libraries that are indispensable to us (e.g. JGraphT). There is a huge community - you are unlikely to run into 'uncharted' territory

- It is popular to hate on Java but it really isn't that bad a language, especially if you aim to follow guidelines like those in Effective Java (probably my favourite programming book) e.g. avoiding mutable state and side-effects. It will never be as good as a modern language like Kotlin (data classes are my favourite feature there), but it is good enough

- The server frameworks available are seriously robust and 'just work'

- There is always the option of using alternative JVM languages (we use Kotlin for a large part of the backend)

In summary, we are 6 months into developing the web platform, progress is rapid, and we have no regrets (yet) about the technology choices. IMO, sometimes boring is best.

Ai Build | London, UK | Backend/Frontend/Fullstack Software Engineers, Data Scientists| Full-time | ONSITE

http://ai-build.com/technology.html

We are an early-stage startup developing large-scale, autonomous 3D printing technology to provide the factory of the future to our customers. We utilise industrial 6-axis robots combined with plastic extruders to print large scale structures and objects (often at a scale of meters). Our current focus is on development of the web platform that is used for managing the printers and generating toolpaths. We are also constantly investing effort into developing our core printing algorithms further.

Tech stack: Dropwizard (Java 8, Kotlin), PostgreSQL, React, Redux, NGINX, Docker, Terraform

We are hiring for several roles

- Frontend (required: 1+ years experience with React, CSS & HTML. Beneficial: experience with 3D programming e.g. ThreeJS, familiarity with REST APIs)

- Backend (required: 1+ years experience with a JVM server framework, REST, Strong grasp of computer science fundamentals. Beneficial: mathematical background/strong knowledge of data structures/algorithms)

- Data Science (required: 1+ years experience implementing modern machine learning techniques in a professional or academic capacity, familiarity with software engineering practices e.g. version control and application architecture. Beneficial: PhD in closely related area, prior experience working as a software engineer and/or a computer science degree)

You will be joining at an early stage and thus will have a large say in how we progress our technology. We are hoping to find fellow engineers who care about code quality and modern software engineering best practices. We aren't into micro-managing and prefer people who have the ability to work independently with minimal guidance.

If you are interested, please contact us at jobs@ai-build.com

Agreed, and presumably there's evolutionary factors here too. If you can't eat you die - having a wound in your mouth that reduces your ability to eat is not good, so there must be strong selective pressures for tissues that can regenerate rapidly. I guess the selective force in the opposite direction might be the caloric demands of healing, hence why we don't regenerate too rapidly.

I think it's more about simply having an awareness of algorithmic complexity. I'm talking about writing a doubly nested 'for' loop and being able to realise that you've just written an O(N^2) algorithm if you're iterating over the original collection again. This sort of stuff is blindingly obvious to experienced programmers but for bootcamp grads who haven't built up that intuition, a short course on Big O notation exposes them to it.

I posted this due to taking a train from London to Swindon last weekend and encountering this exact problem! We nearly missed our stop due to being unable to open the door (and I couldn't see an instructional diagram like the one shown in the blog post).

It's so easy to avoid having them in VCS though. Any secrets can be loaded from a configuration file placed in ~. Populated configs can be selectively distributed so you can e.g. only place the production config file (with the prod server AWS keys for example) on the CI server. Everyone else just gets a config file with non-prod secrets. This can help avoid a lot of mishaps.

You may want to consider using 'stamp files'. These are just empty files created via 'touch' to serve as a timestamp that Make can use to determine if a target needs to be rebuilt if the target doesn't correspond to an actual file in the build directory. This is useful for build targets such as running docker-compose build.

See https://www.technovelty.org/tips/the-stamp-idiom-with-make.h...

Totally agree regarding doctors being fallible humans just like the rest of us. If you are diagnosed with a rare disease (or even just a disease that isn't common in your geographical region c.f. Malaria) there is a very good chance that you, if you are reasonably intelligent and have access to the internet, will rapidly become more knowledgeable in the specific details of your illness than your doctor. This is based on anecdotal evidence of mine through experiences friends and family have had, but I suspect it is a common experience.

- your doctor may not be able to spend significant time getting up to speed on all the details and angles of your particular case

- they probably have no idea about what clinical trials you might be eligible for

- they won't be as emotionally invested in the outcome as you. For most experienced doctors it becomes just a job the best you can hope for is that they are highly professional and take pride in their patient outcome record

- they may misdiagnose you or offer inappropriate or downright counter-productive treatment

- not all doctors are of equal ability. This applies to doctors just the same as any other profession, albeit the minimum bar to entry is usually strictly enforced in most countries

What, serious about wanting to know why it is in their codebase? Yes, I'm 100% serious. If they're currently using it in production I'd assume there's a good reason for it. Plus, I'm pretty sure the folks over at LinkedIn engineering are definitely serious. In any case I'm very curious as to why (rightly or wrongly) it's in there.

What is up with the seemingly popular knee-jerk reactions towards OO design patterns? It genuinely feels like some sort of mass hysteria... Yes, strategies like dependency injection might seem like pointless complexity if you don't examine why they exist in the first place, but they do solve genuine problems. And no, these aren't just problems that wouldn't exist if you used a functional language... (no silver bullets or else we'd all be writing Scala or Haskell)

Yes Java has a lot of problems but they are mostly ones that have workarounds and aren't fundamentally dealbreakers. A few example issues are assignment isn't final by default, @Override isn't required to override methods, you can't have abstract static methods (sort of can workaround this now get this now with default interface methods). Java is basically just a really un-opinionated language that requires careful practices to wield it properly (see Effective Java by Joshua Bloch) but other than that it isn't a completely terrible language and you can write some really robust, easy to read code with it.

I would also have a lot more time for this article if the author actually took the time to explain the motivation behind the *FactoryFactoryFactory class instead of just discounting it without explanation and using it as the proverbial Straw Man for his article. I'm sure something this unusual must have a very interesting reason as to why it exists (I'm taking him literally here and assuming he isn't just exaggerating for comic purposes).

I remember introducing someone to the concept of variance in a set of data and I used a very similar approach. Variance seems like an arbitrary (but obvious) definition but in fact it can be derived from first principles by just looking for the simplest possible function that firstly has some dependency on the difference between values and the arithmetic mean, secondly has the property that it is independent of whether the differences are positive or negative (to the right or left of the mean) and thirdly that it does not depend on the size of the data set (i.e. duplicating each member of a data set would leave the variance unaffected). When you consider each of these, the equation for variance arises very naturally.

Arithmetic difference satisfies for first property

Squaring each difference satisfies the second property

Taking the arithmetic mean satisfies the third property

Var(X) = E[(X - mean)^2]

In my current project (work) I've chosen to use JDBI for communication between model and database. For me it is the perfect level of abstraction whereby it still feels like I'm just writing SQL queries but also avoiding a lot of the boilerplate code that comes with having to manually manage DB connections.

I still have to write the actual code that maps the result set to objects, but I've found this is a very small tax to pay, especially with Kotlin's data classes.

I used an ORM in a previous job (RoR ActiveRecord). I didn't find it an altogether horrible experience, but there where many cases where we would get these 'leaky abstractions' in the wrong direction from the model -> database schema. There were also a lot of cases where we would realise that some ActiveRecord query we were doing was unintentionally loading entire tables into memory (our fault, not ActiveRecord's fault). This was usually remedied quite easily by just RTFMing the docs, but my feeling is we could have avoided it in the first place if we'd used a lower level strategy.

Personally, when developing a new feature I always like to start by thinking about the database representation first and then working my way up. I think having this sensitivity to how it should be represented in the database can allow you to avoid many of the pitfalls that may come with using a more opaque ORM.

Another valuable attribute I get from using JDBI is it's dead easy to mock (like heavyweight ORMs), so unit testing stuff that interacts with it is super simple.

The anecdote about the pink eraser isn't as impressive as the author makes out. A manual google search of 'why are erasers pink' returns the same article from Design*Sponge (that the author mentioned as the source for the response to his voice query) as the top Google result. So, the remarks about how the answer shows evidence of context awareness don't really ring true. The assistant is just passing his question into Google and reading back the response. The sum may be greater than the parts, but nothing revolutionary here.

I worked on a product that used the Vaadin framework for UI. It is a serious, production ready library that is written by some very sane and very intelligent people. The JavaScript hipsters would probably turn their nose up at it, but being purely objective I found it to be a good solution. I have also worked on a project that used React + Redux on the front-end so I believe I have a fairly balanced opinion.

pros:

- Server-side rendering can improve client-side performance, especially since it allows you to avoid N + 1 problems associated with many roundtrips to REST APIs

- Compatibility with all common browsers (Vaadin take responsibility for this basically)

- If your backend codebase is already Java, writing your UI code in Java can save time/reduce complexity (e.g. all your existing static analysis tools can now be applied to your frontend code as well)

- There are simple, well documented ways to wrap 3rd party JavaScript libraries. I was able to integrate VisJS as a custom component quite easily

cons:

- Server-side rendering comes with a non-trivial memory overhead that scales pretty linearly with no. of clients. This may or may not be a concern depending on your requirements

- In terms of writing elegant code, I found the experience much better with React + Redux, as best practices are essentially enforced here (pure functional code)

- You still have to get your hands dirty with CSS, although Vaadin does provide base themes like Valo if you so wish to use them

The centre of mass of the ISS follows a fixed orbit round the earth (to first order approximation that is, occasional thrust is required to maintain this trajectory). Moving away from the centre of mass, by definition, puts you into a slightly different orbit. This perturbed orbit has a different trajectory and orbital speed. This will manifest itself as very small reactionary forces relative to the ISS structure, in other words what you and me call gravity. In plain English, except for at the exact centre of mass position within the ISS (Or any point exactly on the trajectory traced by it) objects will appear to drift.

In the microgravity tower, translations within the experimental container will not result in divergent trajectories, so no drift will occur.

I think you've misread my comment as what you're saying is incorrect. When a qubit is in the state (|0> + |1>)/sqrt(2) it does have equal probabilities of being measured as either |0> or |1>. I think what you're trying to say is that (|0> + |1>)/sqrt(2) is not the only superposition state a qubit can be in. A qubit can be in any arbitrary position of the two possible states.

This isn't a particularly good introduction to quantum computing. The fact that we can't scale down transistors into the quantum realm doesn't have much to do with the real motivation behind making quantum computers. The real motivation for making a quantum computer is that it allows us to perform algorithms that exploit the quantum behaviour of qubits.

To give a concrete example of this, there is a basic quantum logic gate called a Hadamard gate. This takes a qubit in the state |0> and transforms it into a qubit in the state (|0> + |1>)/sqrt(2). The resultant state is what is known as a superposition state - namely a superposition of both the |0> and |1> states. You can think of the |0> and |1> states as being analogous to the 0 and 1 states of a traditional bit. What this means is that when the qubit is measured (read queried) it will return a value of 0 or 1 with equal probability.

The point I'm making is that this is radically different to traditional computing and isn't simply just the next step along in 'valve transistor -> semiconductor -> ?'

Spotify wrote a brilliant blog post on this. Highly recommend reading.

https://labs.spotify.com/2014/02/28/how-to-shuffle-songs/

I think this is a disingenuous argument. Yes the vast majority of the IT field are not experts but if you don't hire one of these experts to secure your system, a system which is aiming to raise $12m, then you shouldn't be surprised when you get hacked.

Also, just because you're not an expert does not mean that you have any excuse to be completely clueless and make stupid mistakes.

Either the average blockchain startup is unbelievably amateurish re. security or this was an inside job. I suspect the latter but the former does not surprise me one bit.

General intelligence evolving independently in another distantly related species implies there is a degree of evolutionary convergence towards this trait given the right selective stimulus. This has implications for the possibility of extraterrestrial intelligence and might allow us to rule out the possibility that 'general intelligence' is an astronomically unlikely event - one of the main candidates for a 'Great Filter'.

This is misleading advice. Most linters can be configured to fail upon detecting a 'TODO'.

I make liberal use of TODOs when developing, typically for reminding myself to e.g. localize a string I've hardcoded during prototyping or to refactor kludgy code.

A pre commit git hook gets triggered to run the linter when I attempt to commit which helps avoid the possibility of adding code containing 'TODOs'. Obviously I can just add the '-n' flag to not trigger hooks, but this requires intention.

In short, using TODOs appropriately is a massive boost to productivity and the alternative is either to just do those random tasks that pop into your head during the course of writing code or to just hope that you remember to do it later.

100% agree. I don't buy the verbosity argument one bit. Yes it's more verbose than a dynamically typed language but it's not like you get nothing in return for that verbosity. When working with serious, mission-critical code, the verbosity (and accompanying clarity) is a godsend.

The only part of writing/maintaining code that I've found easier/more pleasant with dynamically typed languages is writing unit tests (due to the fact that mocking an object is as simple as just declaring a hash literal or JSON object). On the other hand, I find that I need to write extra unit tests to verify integrity that would be be verified at compile time in a strongly typed language like Java.

I would strongly recommend people check out DropWizard. It's an opinionated framework for writing Java servers that comes with a handpicked stack. It has many of the convention driven advantages of e.g. Rails but fundamentally you're still writing code in Java (or another JVM language like Kotlin).

The main issue I have with this feature is that as far as I can tell there is no way to opt out. I don't want this feature and I choose not to respond to the notifications I occasionally receive when there is a terrorist event in my city. That leaves me in a bind - unless I tell friends and family who use Facebook that I'm actively choosing not to use the feature, they invariably begin to worry about me when I don't 'mark myself as safe'. This to me is unacceptable.

For me a large part of the reason I use Vim and only Vim for writing code is it just makes the experience so much more enjoyable. I realise this is quite subjective, but my personal experience is that whenever I use a colleague's non-modal editor I find the experience frustrating even though I know how to use it. Years of using Vim has sensitised me to the constant annoyances that accompany using a conventional editor.

Has Vim sped up the rate at which I can edit text? Probably, but for me this is missing the point.

I'm not a physiotherapist but being able to rest my forearms/wrists on the table 99% of the time when using Vim significantly reduces the risk of RSI.

I attended a lecture course on quantum information given by a young professor who was a direct descendant of Erwin Schrodinger. He didn't find out he was descended from him until mid-way through his PhD.