Getsafe | Senior JavaScript Engineer, Senior Backend Engineer (Ruby) | Heidelberg, Germany (can help with relocation) or REMOTE (Germany/UK)| https://hellogetsafe.com/career
Getsafe is a fully digital insurance company that allows you to cover yourself and your universe simply from your smartphone. Opt in, opt out, switch it, change it, make it yours. It’s 100% digital, you know exactly what is covered and what is not, and you pay only for what you need when you need it.
Our tech stack is React/React Native and Ruby/Rails running on Heroku. We're looking for engineers to help us build a more scalable frontend and backend so we can keep expanding to new insurance products and markets (we recently went live with car insurance in Germany among others). Insurance is one of those things a lot of people look at as boring, but we're looking to make it easy and fun for people.
Getsafe | Senior JavaScript Engineer, Ruby Backend Engineer | Heidelberg, Germany ONSITE (can help with relocation) or REMOTE (Germany/UK)| https://hellogetsafe.com/career
Getsafe is a fully digital insurance company that allows you to cover yourself and your universe simply from your smartphone. Opt in, opt out, switch it, change it, make it yours. It’s 100% digital, you know exactly what is covered and what is not, and you pay only for what you need when you need it.
Our tech stack is React/React Native and Ruby/Rails running on Heroku. We're looking for engineers to help us build a more scalable frontend and backend so we can keep expanding to new insurance products and markets (we recently went live with car insurance in Germany among others). Insurance is one of those things a lot of people look at as boring, but we're looking to make it easy and fun for people.
This isn't an sdk issue, it's a purposeful decision by Niantic to not support beta OSes to avoid potential exploits. Fwiw it finally works now with the 14 GM that went out :)
Roadads (https://www.roadads.de/, I can't seem to find an English version of the site) is an interesting idea of trying to apply some of these tactics, but adds location to the mix. Eg. advertising for a specific restaurant at the next exit. They're giant e-ink displays though instead of LCDs. That could probably be used stationary too, anywhere full color ads are less important.
Parts of this are in other comments, but I find a couple things help code reviews enormously to be more efficient.
1) Automatic code formatters/linters before the code gets to review. When everybody knows there's a formatter, reviewers can spend less time looking for formatting issues. Generally, people are more inclined to take a quick look at the code then too, because they know their focusing on "just" the logic, which helps with getting a review sooner.
2) Smaller sets of changes up for review. Yes, this might mean more code reviews overall and more process, but it's way easier to catch a bug in a < 100 line change than in a 1000+ line change. This also means keeping the contents of the review as focused as possible. If you want to refactor some major chunk of code because it makes the actual thing you're trying to do easier, go for it, but do it in a first code review and separate the logical changes. This goes to both reviews being more straightforward for the reviewer to get through and them wanting to do it in the first place. I'm way more likely to avoid a massive 30 changed files code review than a quick 5 line change, because I need way less focus to review the latter.
3) (this one might be controversial) Early code reviews where appropriate. If you're making a change that's more likely to be totally rejected, get it into code review as soon as the basic structure and logic is in place and ask somebody to review it as quickly as possible. This is before tests are ready and every todo is completed or whatever else. The review should be quick and dirty, but at least that way you know if you should be proceeding with your current path at all or change course. Again, this means more time spent reviewing, but it's a lot better than getting a review after a week saying what you just wrote has already been done, or it totally misses goal, or it has some critical issue, or whatever. This helps a lot with what to do while you're waiting for feedback too. If you've got this type of code review up then you can keep working on the details while you're waiting on feedback. If your code review doesn't fall into this category, you're probably relatively safe to start working on the next thing, because at most you'll need to make some small changes to what you're working on, not throw it out altogether.
4) Making sure code review is considered a priority on the team. That includes the team lead prioritizing code reviews and encouraging others to prioritize code reviews. If the code doesn't get reviewed, it doesn't get shipped, so it's ultimately more important than writing new code.
Glad teachers are finding a way to make some additional money especially given how much time they spend on lesson plans. The licensing aspect seems interesting and potentially problematic, but I don't see why the school districts couldn't get into this too and do some sort of revenue share with the teachers (ignoring the bureaucracy of actually setting it up). A more "open source" version of this would be nice too but then you get into the same kinds of funding issues that open source projects have. Seems like it would be good to have teachers contributing back improvements though too. Does anybody know of anything like this?
