Chameleon | Fullstack Engineer (Ruby) | Remote before it was cool | $120k - $180k | Full-time | https://chameleon.io
Remember those modals, tooltips and checklists you have built but never really wanted to?! with Chameleon, the Product team can WYSIWYG those into your application with just a few clicks.
We're a great, growing team looking to hire a Frontend and Fullstack Engineer to complement our existing expertise. If you're in the Americas, take a look at the role description and see if you'd be a good fit
Chameleon | Frontend Engineer (React) + Fullstack Engineer (Ruby) | Remote before it was cool | $120k - $180k | Full-time | https://chameleon.io
Remember those modals, tooltips and checklists you have built but never really wanted to?! with Chameleon, the Product team can WYSIWYG those into your application with just a few clicks.
We're a great, growing team looking to hire a Frontend and Fullstack Engineer to complement our existing expertise. If you're in the Americas, take a look at the role description and see if you'd be a good fit
How you do you solve for, or imagine solving for the hiding of potentially important UI without running to risk users not finding what they are looking for and not realizing it is "just hidden". Without having to first know that they are missing something, how will they know? Is there a partial-hide?
Chameleon | Frontend Engineer (React) | Remote before it was cool | Full-time | https://trychameleon.com
Remember those modals, tooltips and checklists you have built but never really wanted to?! with Chameleon, the Product team can WYSIWYG those into your application with just a few clicks.
We're a great, growing team looking to hire 2 Frontend Engineers to complement our existing expertise. Take a look at the role description and see if you'd be a good fit!
Chameleon | Full Stack Rails Engineer + React | Remote before it was cool | Full-time | https://trychameleon.com
Remember those modals, tooltips and checklists you have built but never really wanted to?! with Chameleon, the Product team can WYSIWYG those into your application with just a few clicks.
We're a great, growing team looking to hire 2 Full Stack Engineers to complement our existing expertise. Take a look at the role description and see if you'd be a good fit!
Client side JS is Backbone + HTMLbars
Node.js
Rails
AWS Lambda
MongoDB & Postgres
We have some interesting requirements that we must conform to in order to be part of our customer's web applications. We'd love to explore those constraints and benefits with you.. Brian - co-founder @ Chameleon
We've all built and [not] maintained product tours, now its time to pass the torch to our business compatriots. Chameleon enables them to show off the product without developers as the linchpin for the whims of late-night copy changes.
We've built a product that runs wholly inside another companies interface allowing them to create and edit right where it matters (engineering wise there are many challenges this presents).
Our engineering motto: If product can think it up, we can built it -- all product needs to do is figure out what is most important ;)
Instead of assigning a variable or bloating the length of your statements, use this method to to return the caller and only execute the block if the condition passes.
This is good information, but could you explain why you think that everyone should use caching? You don't mention testing in this article so is it safe to say that you don't? Do you have performance tests that show that the caching actualy matters for you application workload?
This is the point I was getting at. Not that this style is bad or good (I think it is good) but that these aren't tests that span modules.
It is common practice (and a good one) to mock the server from the JS perspective as to isolate it, but I dont think this in itself gives it integration test status.
For example this line states that if you are given 20 records that 20 make it into the view.
expect(view.$('.persons li').length).toEqual(20);
This mocks out the server to give 20 results back and simply tests that the template iterates over the returned collection (given that the 'reset' binding for view.render is in place). You are specifically not in an 'integration'.
As for the argument for not using capybara for speed reasons - it seems that the speed difference is acceptable given the confidence and power it gives you.
This is not the same as an integration (acceptance) test. Whence you mock the server you can no longer be confident that a breaking change was not introduced across the stack.
The purpose of integration tests is that you are the user, and express your functionality in the same manner that the user would.
This is not that. It is therefore not an integration test.
We're a great, growing team looking to hire a Frontend and Fullstack Engineer to complement our existing expertise. If you're in the Americas, take a look at the role description and see if you'd be a good fit
Fullstack: https://trychameleon.notion.site/Fullstack-Engineer-be6a2017...