Since you're saying you are in the Denver area, you should follow Colorado state law and actually post the compensation details on your listing/website.
Campspot creates reservation and management software for campgrounds, and uses this to power an online marketplace for booking campsites.
We are looking to hire a CTO (my current job) to manage and grow our engineering organization. I plan to stick around and move back into a more technical/contributor role.
Full Stack web developer: https://www.campspot.com/software-developer
Tech stack it Java/Kotlin with Dropwizard on the backend and Angular/Typescript on the frontend. Lot of AWS stuff too. Looking for 2+ (not required to be in our tech stack) years of experience for that right now.
Campspot | Senior Full-Stack Web Developer | Full-time | ONSITE | Denver, CO | 100-130k
Tech Stack: Modern Java 8 and some Kotlin with Dropwizard. Some legacy Node Stuff. AngularJS frontend.
Campspot creates and maintains best-in-class reservation and property management software for campgrounds. We focus on providing easy online reservations and business rules that maximize revenue and inventory capacity for campgrounds.
We are looking for a senior developer to help lead our growing team and help us expand into some additional products in the future.
Campspot is hiring a senior full-stack web developer. We’re a startup that creates online reservation and management software for campgrounds.
Our development team is really small right now (3 devs) but we have a ton of positive growth on the business side and are looking to expand. Whoever gets hired into this role will have the opportunity to have a big impact on our culture, technology, and business.
Our stack is Java on the backend (Java 8 and Dropwizard, no XML) and Angular 1 on the front end (considering options to change that going forward, haven’t decided on anything yet). Experience with any part of our stack is a big plus but not a requirement.
This is a full-time permanent position, not looking for contractors or freelancers.
Feel free to email me (al.scott at campspot.com) and ask any questions about Campspot, the position, or our technology.
Campspot is building a next generation campground reservation and management app. We are already being used in a number of campgrounds around the country and have a relationship with a major campground franchise.
Our stack is Java 8 and Dropwizard on the back end and angular 1 (might change in the future) on the front end.
Campspot | Anywhere USA | Full Time | REMOTE | Dev Ops
Campspot (campspot.com) is looking for an experienced DevOps Engineer. Our stack is Java (Dropwizard), NodeJS (Loopback), and Angular. All of our infrastructure runs on AWS.
Our engineering team is entirely remote with the US. Come join a small, awesome team working on revolutionizing the campground industry.
I don't think doing code reviews implies a lack of trust. I trust everyone on my team but we code review everything. For that matter, the fact that we trust/have good relationships with everyone makes code reviews more effective because we can be more candid.
We often find issues in code reviews like edge cases that weren't thought of, code that could be refactored to use an existing utility or patter the author wasn't aware of, etc.
I work for a company that averages around 50 production deployments per day for our customer-facing ERP, and we only do code reviews for new devs and changes to underlying framework changes for mostly the same reason sklivvz1971 mentions. We rollback very infrequently and a majority of our devs can deploy to prod with the push of a button as needed (this includes both application and database code). Not arguing that code review is unnecessary, just feel that with proper training and having devs with good judgement can help reduce the likely hood of breaking things when deploying small changes frequently.
We rarely catch things breaking in code reviews, I agree they are really bad at finding bugs. Automated tests and linters are better at finding stuff like that. The things we usually address in code reviews are architecture and code design issues, and occasionally edge and interaction issues that are outside the scope of what might have been considered when implementing.
We also have frequent production deployments that everyone on the team can do, I view that as something that is independent of code review.
Not a bad practice, but costly in dev time and a trade off many aren't willing to make especially in smaller companies where mistakes aren't as costly as all that extra developer time.
Personally I do code reviews mostly to share knowledge and culture rather than looking for bugs. Occasionally a bug is found, but I don't generally have the time to review the logic, just the style.
Don't get me wrong, we review code. We simply don't review commits. Reviewing absolutely every commit would feel like a waste of our time and an efficiency issue. I can see where it could be useful, but in our case it's simply a solution to a problem we don't have. We can definitely live with a bug in production for 5 minutes.
As a commenter below notes, there are always two pilots in an airplane -- and that is pretty much also a trust issue -- but we don't pilot planes, we don't have actual lives depending on us.
Your project files must have "correct" format, e.g. require('relative_path') for imports and module.exports/exports for exports (or es6 import and export). Example for AMD format (requireJS) can be found here - http://ternjs.net/doc/manual.html#configuration
>Tern supports node.js module loading so this should work across modules.
This hasn't been my experience. I've tried various term commands and configuring tern to do things like eagerly loading project files, but it still only works for me in a single file. Do you have any links to docs on how to do this?
I literally just installed tern in atom a few minutes ago and it works. This is the .tern-project file I generated, but I have no idea if it's optimal.
