NovoLabs | Dallas, TX | Full-time | Onsite or REMOTE
NovoLabs is a small team focusing on Conversational Commerce in the Restaurant Industry. Our vision is to provide a world class product that allows users to transition from an analogue channel like a Phone or Drive Thru to digital channel.
We're 18 months old and have recently begun taking Transactions from well known restaurants!
As we are still small, we are looking for highly capable, high impact, deep generalists or expert level React / Graphql people.
Our current stack includes: Clojure, React, Graphql, Scala, Finagle, Google Cloud, Kubernetes, Postgresql.
We offer a highly competitive package and would love to hear from you! If you're interested please email me with any questions: [email protected]
I've been jumping between AWS and Google Cloud ( with a bit of Digital Ocean sprinkled in ) for the last several years. I chose Google as our cloud platform when we founded our company last August. I could War and Peace a bunch of things but that article does a very nice job in the details. Instead, I'll give a one liner:
AWS is to Linux as Google Cloud is to FreeBSD. "Rock solid performance and everything is exactly where you think it should be"
I'm happy for the guys at Bouyant, they've been great to work with in the past.
There's a very large complexity payment inherent in the new "cloud native" architectures that fundamentally isn't worth it for a large swath of use cases. Conduit, at first glance, appears like it might solve a large portion of it. If there's anything the last 10 years have shown us as an industry, it's that convention and programmer ease of use are the most important qualities of a new framework or way of working.
Rails / Go / K8S dominating Mesos / Containers over Jails / Maven over ANT / on and on. ActiveRecord is great, and Rails routing is great. Together they are magical for what they provide a user. Envoy is great. Istio is great. But there isn't a simplistic way to unify them even though for 95% of the industry it appears their functionality should go hand in hand.
Nokona gloves are almost comically well made. I've used mine for over 20 years at this point and outside of a once a year oil'ing it has held up remarkably well. My dad has his from the early 60's and while it looks worn ( he hasn't taken care of it ) it's still very usable.
Alan Jacobs has a pithy overview of Morton, and the following is taken from a recent post on Morton by him:
This strategy of employing familiar language in unfamiliar contexts gives the appearance of being radical but may not be quite that. It strikes me as being largely a reversal of Skinnerian behaviorism: the behaviorists said that human beings are nothing special because they're just like animals and plants, responding to stimuli in law-governed ways; now the object-oriented ontologists say that human beings are nothing special because animals and plants (and hammers and black holes) all possess the traits of consciousness and desire that we have traditionally believed to be distinctive to us. The goal of the philosophical redescription seems to be the same: to dethrone humanity, to get us to stop thinking of ourselves as sitting at the pinnacle of the Great Chain of Being.
It's hard for me to take Morton too seriously because our ( by which I mean his and mine ) Metaphysics are so diametrically opposed. Hyperobjects are so ontologically complex as to give the feeling they have been invented solely to justify the philosopher's pre-existing beliefs ( though in fairness, you can write that about a lot of things ).
You're 100% correct. Sorry about that, my fingers didn't translate what I had in my head in regards to pkgng replacing the old separate multi-component way of handling binary packages.
My understanding was that pkgng is a architectural overhaul in addition to a simple client clean-up - configuration is different for example. What I was trying to get to was that the newer design is barely two years old in production. I should have written this more clearly and did not, thanks and sorry.
That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them.
The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vast tree of Makefile's allowing you to create custom builds of virtually any software imaginable.
While pkg is still raw on the edges, I VASTLY prefer it to Debian's hodgepodge of package management tools that all do 90% of the other, though none of them do it cleanly and none of them have straightforward interfaces. Am I using dpkg here? What about aptitude? Or should I just roll w/ apt-get? All of these tools combine the ease of use of git with the flexibility of a Maven build. If you know how to use to descend deep into the depths of git or Maven, this isn't an issue ( and for the author, it certainly is not ). Yet there are numerous simple tasks ( like say, searching for a package remotely when you aren't sure the exact name ) which still require hitting up google and settling in for a Click-Your-Way-To-Adventure session.
PKG, in contrast, is both simplistic and flexible ( it reminds me of a industrial grade version of Brew in some sense ). It's a tool that I find myself integrating into my workflow beyond simple installs / updates, particularly it's seamless integration with jails. Configuration of remote repositories is vastly simplified as well.
PKG is not perfect by an means - it definitely has worts that need to be taken care of. I'm also sure that PKG probably feels a tad inadequte to some hard core sys admins - pkg has the look and feel of a tool designed by a programmer looking to handle normal cases than a tool designed to provide a sys admin with an atom bomb if necessary. Yet the system is still relatively new and as the bugs continue to get ironed out it's a reminder to me of why I love FreeBSD in a lot of ways - the abstraction point is flawless and it gets out of my way.
Scala is much closer in spirit to ML / OCaml / Haskell than a LISP dialect, but I do agree w/ you that Scala rocks. It's my favorite language I've picked up since O-Caml.
Man that's a bad post about Scala. Scala has a lot to love and a bunch to hate within the language itself, but writer doesn't appear to have the ability to actually discuss it.
The difference between the high quality math guys and the high quality distributed jocks at that level is much larger than I think most people think. I come from the engineer side, and it's really bizarre to hear people w/ Ph.D.s in machine learning or physics give talks where they will mess up what is really a junior level distributed programming concept. Happened twice at Strata that I saw. Mind you, that's for BASIC things, not someone trying to right a highly concurrent computational system across hundreds of nodes. No lie, I had a conversation with a machine learn jock that asked me point blank when we couldn't make Matlab go faster.
On the flip side, the distributed engineers might even be worse at the math than the data jocks are at programming. A middling concept for a machine learning guy, like say a Bayes error, is like trying to write concurrent state machine in assembly.
tl;dr - the pool of people that are both elite math jocks and elite system jocks is vanishingly small, as in I would be shocked if that number was out of the triple digits world wide.
Julia has a lot of promise in that it gives the math guys familiar syntax, but appears to have the underlying capability to be very fast on shared memory architecture. It's already got the handles to call out to python / C / Fortran bindings.
Dr. White, who heads this up, spoke yesterday at Strata . . . it was the most bizarre talk I heard in the 3 days by a mile. At one point, he actually put a slide from a Wired peace that bashed him, then spoke for about 45 seconds about how the piece was wrong when no one in the audience really cared. He's just an odd duck.
On this, he put forth a really solid vision of what he sees coming out of this - a classic melding of Machine Learning dark arts with the ease of use of a traditional, modern web framework. It's a pretty bold vision, but he's got the cash to spread around to certain contributors.
It's worth trying to grind through a few months of Free-BSD after using Linux to get a feel for it. One of my favorite quotes on the differences is, "FreeBSD is what you get when a bunch of old school Unix beard brigade hackers sit down to write a port to the PC. Linux is what you get when you take a bunch of hackers raised on Windows and PCs that try to port Unix to the PC". In a lot of ways that is two sides of the same coin, but really digging in to the BSD way of things opens up a new view point on Operating Systems . . . FreeBSD old school Unix assembly versus NASM, the Kqueue vs ePoll system implementations, FreeBSD's near instantaneous embrace for ZFS while the Linux community held back for "OS theological" concerns over the FileSystem implementation.
I've jumped between Debian and FreeBSD for my development boxes for a few years now. To butcher Dijkstra, "Operating Systems shape developers as much as violins shape violinists". When I find myself on FreeBSD I make great use of D-Trace - running vagrant FreeBSD boxes, the pulling the trace output into Instruments to analyze. With the release of Trim for ZFS, ZFS pooling for logging should be obscenely fast and offer some serious performance increases for things like proper Hadoop workloads. When I find myself on Debian I'm enthralled by the ease of use around layouts and the API ( kqueue / epoll excluded ). The package management system is far superior to portsnap, though neither system really does modern package management really well imo.
Personally, I think it's worth trying to run BSD and all it's tools just to understand the system better, and to see how it influences you as a developer. The active utilization of D-Trace changed me as an engineer just as much when I first started using functional programming concepts in my regular code
I've done a lot of Spring side work and your first paragraph is the best explanation I've ever read for the framework.
I also agree that if you can't test Spring code you are doing something wrong. I get the frustration with having to create test harnesses for some things, and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never seen well written Spring code that wasn't easily testable at the both the class and module functionality layer.
This article confuses me . . . a better title would have been, "Why we changed languages, went from PaaS to IaaS, and changed our datastore - or why we changed everything". I find it interesting that the author didn't go from AppEngine to Heroku, which has robust NodeJS support, Memcache and Mongo support as well.
I applaud the author for making changes to support their business more effectively, I'm just not sure what I'm supposed to take away from this other than someone successfully changed some stuff.
This is 100% correct. Southwest uses SAAS, which is so old that last year they begrudgingly updated because the Big Iron SABRE was using to host these things was no longer being supported by IBM.
SAAS is mostly a Sabre Product at this point though, Southwest has requested so many modifications at this point that SAAS is basically custom.
In the industry, ALL reservation and ticketing systems are written by specialists. The major players are Sabre ( think IBM ) / Navitaire / ITA ( which was bought by Google not too long ago ). Southwest is a great company, and they pay well, but their engineering staff is made up of the neckbeard brigade . . . lots of guys in their 50s that have either retired before retiring, or finally decided to learn this new fangled "java" language and move on from C and COBOL. There is simply not the engineering skill, nor the organizational will, to develop anything that complex in house. They tried once about 5 years ago and after 4 months it exploded in a ball of flames because they couldn't solve the the throughput issue.
This outage was almost certainly a Sabre issue. The reservation system itself runs on old school IBM big iron written in C. The system is so damn old that when you go southwest.com, all the information retrieved is done via screen scraping. Not XML, not JSON, not even CORBA. The key point is when the spokesman describes the "weight" of the airplane, something that is calculated by the system according to how many people checked in, how much luggage, etc. Without the system up and running, the flight cannot be "closed" and therefore tracked properly.
Southwest hosts all of their own in house applications ( except for a few things on GCE ), but the Sabre system is run out of some nuclear proof bomb shelter in Tulsa. It goes down 1 ~ 2 a year, but typically it's only out for 10-15 minutes. For planes to be called back to the gate, the outage would have had to have been over 60 minutes, as that's how long they buffer in a separate system in case it does go down.
Finally, Southwest pays Sabre by . . . wait for it, requests executed per second.
It's written on the JVM for the simple reason that if they wrote it in Go or Erlang, no Enterprise would adopt it as there isn't a CTO at a non-tech Fortune 500 that has every heard of Erlang or GO, and wouldn't know the first thing about trying to hire developers for it. Remember, the jobs written for Map Reduce are done in the same language ( typically ) as the MapReduce code itself.
NovoLabs is a small team focusing on Conversational Commerce in the Restaurant Industry. Our vision is to provide a world class product that allows users to transition from an analogue channel like a Phone or Drive Thru to digital channel.
We're 18 months old and have recently begun taking Transactions from well known restaurants!
As we are still small, we are looking for highly capable, high impact, deep generalists or expert level React / Graphql people.
Our current stack includes: Clojure, React, Graphql, Scala, Finagle, Google Cloud, Kubernetes, Postgresql.
We offer a highly competitive package and would love to hear from you! If you're interested please email me with any questions: [email protected]