nuvoair.com | Full-stack engineer | FULLTIME | ONSITE | Stockholm, Sweden
No visa sponsorship available. You must have permission to work in EU.
We are a small but fast-moving funded (2017) digital health start-up changing the way healthcare is delivered. We combine hardware, software and data to improve lives of people suffering from respiratory conditions and to enable better clinical decisions.
Your key responsibilities are to build, test and maintain architecture. Discover opportunities for data acquisition, and to assist scientists with data modeling, mining and deployment.
Your skill set and qualifications include: Minimum 5 years of commercial software development/ Python, Django and Flask frameworks and SQL / Strong linux command line a plus -- GIT/Jenkins/Docker/etc -- Testing (unit and integration) / Strong communication and documentation skills (fluent in English)
What we offer:
- Competitive salary incl. pension plan
- Opportunity to participate in our option plan
- 6-week annual leave
- Subsidized gym membership
- English speaking office in central Stockholm
- A fast-growing startup
- The opportunity to shape the future of healthcare
If interested reach out with an intro and CV/github/portfolio to sheraz.sharif@nuvoair.com
You make a valid point. One thing that I don't like about other frameworks is that the styles come across a bit childish. The original intent was to create something that would allow you to make something that actually looks good without a lot of effort. It's not there yet, but I wanted to share to get some feedback and maybe even a few more contributors so I could hit that goal.
I moved off of swarm and back to regular docker after taking a hard look at our needs and infrastructure. Turns out we don't need all the clustering and scaling magic of swarm or kubernetes.
In fact, this has greatly simplified our development, testing, deployments, monitoring, and recovery.
If I need to scale then I add more cores to a machine with minimal downtime. No need for all this rolling upgrade stuff (at least for my applications)
Perhaps rather than using bootstrap on a high stakes project (like client work or apps with paying customers) you could try bootstrap customization on a low risk side project? That way when (not if) your screw it up there is no anxiety of an angry client or customers demanding a fix? There is no anxiety of having to support IE or some client’s esoteric dom-modifying browser plugins.
This way you can learn at your own pace and really get s feel for the codebase and workflows for bootstrap customization.
Yes. Wildcard certificates are useful primarily as an alternative to manually managing many certificates. But in the age of automation (now), LE wildcard certificates are only really useful to avoid rate limits, which is 20 certificates per week per set of names.
Key compromise for a single site is much less disruptive than losing control of a key that protects hundreds or thousands of sites. Generally you want to keep your scope smaller, it's safer. Rather than blanket-verify everything. Wildcards also makes it more difficult for you to see what of your names is going through CT logs.
Caddy will support wildcard certificates, but most users will not need them, because already Caddy can obtain certificates "on demand" - dynamically, during the TLS handshake. Again, the main reason for using wildcards at this point would be to reduce pressure against LE rate limits.
I imagine so, too. If you have N machines each serving a different site, better to have each only have a key valid for its site so there's less impact from one of them being compromised.
btw, in that scenario, even if the sites all share an IP address, you can use a TCP-level proxy that supports doing the TLS SNI exchange to determine where to send the connection on, so the proxy doesn't need any of the keys and the encryption is end-to-end.
Yeah, I think that if someone hacked your DNS provider, they could add secure-payments.yourbusiness.com and start spamming people with "late payment! enter your credit card!" notices or something.
So I guess, make sure you trust your DNS provider if you're using wildcards. Or is there another exploit I'm missing?
They would need to both hack your DNS entries and have access to the private key of the pair for which the certificate was signed. Having access to the private key probably indicates a significant hole in the site's infrastructure so that is more of a concern than DNS.
Of course such access may be easier for a disgruntled internal actor so it is a risk worth considering (and mitigating via proper separation of concerns/access).
Not sure how the availability of wildcard certs changes that scenario, if I can set the DNS record for secure-payments.yourbusiness.com then I can get a non-wildcard cert for it and get on with the spamming straight away
I think it's somewhat difficult to get a valid (CA-valid) certificate for a domain you don't own, though. At least, that's what the job of the CAs is: to verify that the certs they're issuing are for the actual owner of yourbusiness.com.
I thought that was the case, until CloudFlare issued a cert for a subdomain of mine without a single email round-trip or even notification.
Any DNS-based validation is contingent on full DNS control, and that does mean FULL. CNAME records are absolute, if I CNAME foo to xyz then I'm trusting xyz 100%. I won't get an email round-trip or CAA ping for the certificate unless I'm looking for it, because CNAME implies that all things that apply to xyz apply to anything pointed at it. So the CAA record for xyz applies, not the CAA record for foo - it's not even valid to have any other record types for the same name as a CNAME record, and CAA resolution stops if it gets a valid response versus walking up to the domain root.
To be clear: CloudFlare issued a perfectly valid certificate for a perfectly valid use case, it just bothers me that I couldn't tell it was issued until after-the-fact by seeing it in CT logs, and couldn't have prevented it from being issued by the mechanisms that seem to be built for that.
That sounds like the description of an EV or OV certificate, where the CA takes additional verification steps.
LE is all about DV certs -- you just need to control the web server at secure-payments.yourbusiness.com, and with DNS control you can aim secure-payments.yourbusiness.com anywhere
Nope, DV certs just verify that you control the domain (i.e you can place arbitrary content in a specific location). You don't need to own the domain otherwise SSL would be a lot harder for mysite.hostingcompany.com type providers.
In hindsight I have been guilty of resume-padding and falling prey to hype by choosing to build on technology not appropriate to the problems at hand. And I find myself reverting back to basics, with bits of new tech sprinkled in.
My reversions:
- React, flux, redux ----> jQuery and intercoolerjs when needed
- Swarm, Kubernetes ----> Just plain old docker on single machine, scale vertically with cores and memory when needed
- Microservices first ----> Django Monolith first, then break out microservice when needed
- API Gateways (kong, Azure) ----> Nginx reverse proxy with hand-edited configs.
I can do this because I have chosen to work on niche problems and smaller markets. Scale is not my issue, even in very successful scenarios.
I see jQuery will have a place in my stack for some time to come. It just works (tm), and it plays well when I need to level-up with wither intercooler or yes -- backbone.
Another benefit is that it is a low barrier to entry for junior developers. It allows me to establish a baseline knowledge, and then mentor other things like workflow, code structure, and architectural things rather than chasing weird configuration things inside of webpack or the taskrunner-du-jour.
Your reversions resonate with me very strongly, even down to the exact tech choices. While the industry seems to chase ever increasing complexity, I believe 90% of web applications would be served more than adequately by jQuery, intercoolerjs and Django running in a single container that can scale horizontally if necessary on Elasticbeanstalk. (eb deploy.. Done).
But, sadly, it feels like openly selling yourself as a consultant in these technologies would be a form of sabotage and limit your opportunities considerably.
I've just had an idea for branding myself: artisinal, vintage web development using traditional jQuery / Django. :)
I might agree with you and your parent. My objection would be that I all too often experienced that seemingly small projects turned out to grow into huge applications. And previously accumulated tech debt is hard to get rid off.
So I mostly start out now with my own boilerplates. React + Redux is one git clone command. Docker including Service Discovery (Traefic, Registrator), RabbitMQ and MongoDB is another git clone [1]. So I am productive immediately and the right tech is in place.
Regarding the discussion Micro-Service vs Monoliths. I agree that a monoliths gets you started quicker. But it also asks a lot of discipline from the programmers. E.g. 'stick to your domain boundaries', 'Don't take that shortcut of direct db access because business needed the feature yesterday', etc. Otherwise you'll have big troubles splitting it up later on. [2].
I REALLY REALLY REALLY like that micro-services make your boundaries explicit and enforce you to write contractual APIs aka Interfaces. Much more than all the promises of scalability etc.
If I look at the last two, it was 6 month and 9 month. The first one was initially thought to be just another search engine for some of the company's content. Then it got transformed into the main data store including CMS and all those nicetees. In the end, 7 people worked on it.
The second one was a tool used only internally by my customer's employees. They then sold the idea to some of their customers and it had to transform into a full fledged product. 4 people are now in charge of it.
I am still coming back to projects sometimes where I didn't do this and I hate every minute hacking on them -.- 'Wish I would have just used React or whatever' are often my thoughts then :-)
How are those big projects? Why would you need any scalability for that?
From what you just said they're running for, at most, a few thousand people.
In terms of loads/numbers/etc. that's child's play and definitely not "huge applications". The kind of decisions he's talking about are for things with thousands of concurrent users per second, not per day.
That kind of stuff could be dealt with a single desktop computer running PHP and mysql. And you definitely don't need microservices.
In my experience, having worked in both enterprise and consumer startups, enterprise is shallow but broad with little need for any of the complicated stuff and more need to make the code really simple, obvious and uncomplex because it ends up dealing with so many different problems, while consumer scale is where you start needing to get a bit fancy purely because of scale, but it only deals with a couple of problems.
To quote myself regarding micro-services: "I REALLY REALLY REALLY like that micro-services make your boundaries explicit and enforce you to write contractual APIs aka Interfaces. Much more than all the promises of scalability etc."
With huge applications, I mean 10s of thousands of lines of code with features added on a daily basis by multiple developers.
What both have in common is that they started us as seemingly small 'throwaway tools' but grew into business scale applications that serve now a core purpose.
Again, "10s of thousands" of lines of code is nothing. It's a few months work.
Introducing microservices into a small code base feels like it would be counter-productive. It adds a ton of unnecessary complexity to a tiny code base.
You don't want contractual APIs for code like that, as it grows the contracts are going to be constantly breaking as new features are added and the only people who care are the other, internal, developers.
If you used a statically typed language, in a monolith it would tell you immediately that it had happened as soon as you did your sync (which should be happening multiple times a day for everyone). Better still, the other developer would have had to deal with it, the only code you'd need to worry about is the new code you added, and again, your check in would break the build.
Code how you want, but my mind boggles at people doing microservices for tiny code bases. Much better to have a monolith until you get into the million of lines.
I am just thankful I work on statically typed monoliths where my tools just deal with it and I don't have to spend time setting up and debugging microservices instead of doing actual work.
Thanks for telling me what I want :-)
I also worked on statically typed monoliths (.Net)! I also worked on micro service systems (>70 services, 2 years of work) written in NodeJs.
Sure, but there is a bit of relativism here, isn't there? A 10 year-old might consider Coldplay an oldie the same way a fresh javascript developer might consider jquery old legacy stuff despite the fact that both continue to make releases.
I think if you are selling services as a consultant then perhaps sell the solution rather than the technology behind it.
When I buy a car I’m buying the benefit of it, which is convenient transportation. I don’t really think that I’m buying a drive train, engine, steel body, airbags and whatnot.
This does result in a “hiccup” for any clients wanting to connect. They will see a 502 gateway error at which point they should retry with exponential backoff.
And that is the trick — make the client retry with the exponential backoff. Document it as the expected behavior when that event arises. And for our traffic patterns this is acceptable.
I am very aware of that but overall it still looks like it if you have a look at all topics, personal stories and experiences etc.
I'd be rather fearful to go the the US, starts at the border, then their cities and then I'd be fearful of their police.
Not to mention all the other issues this country seems to have. The poverty in the USA is worse than in some ex 2nd world countries, so bad that even the UN called upon it.
How many hundreds of thousands pass through American borders with little hassle every day? That is not news (but maybe it should be as well).
Also, one cannot paint with such a wide brush as "The USA." It is the same mistake as any American visiting London, Paris, and Berlin -- and then saying they have seen "Europe." They didn't see Europe -- they saw globalized mega-regions that happened to be located on the European continent.
Unfortunately, Baltimore is an outlier when it comes to violent crime, corruption, and poverty. It is an urban center in decline and in need of all kinds of help. (This is where I stop, else it becomes political very quickly).
Compare Baltimore to places like Denver, Dallas, or Phoenix, and you will see very different cities. The US is huge in geography, population, and economics. Pinpointing an outlier and concluding that the entire country is poor and dangerous does not make for constructive conversation.
We would do ourselves a favor to talk more about the specific problems Baltimore faces, and then look at the broader American context to see which sister similar cities have tackled similar problems.
No visa sponsorship available. You must have permission to work in EU.
We are a small but fast-moving funded (2017) digital health start-up changing the way healthcare is delivered. We combine hardware, software and data to improve lives of people suffering from respiratory conditions and to enable better clinical decisions.
Your key responsibilities are to build, test and maintain architecture. Discover opportunities for data acquisition, and to assist scientists with data modeling, mining and deployment.
Your skill set and qualifications include: Minimum 5 years of commercial software development/ Python, Django and Flask frameworks and SQL / Strong linux command line a plus -- GIT/Jenkins/Docker/etc -- Testing (unit and integration) / Strong communication and documentation skills (fluent in English)
What we offer:
If interested reach out with an intro and CV/github/portfolio to sheraz.sharif@nuvoair.com