Pass data from backend to javascript is done in many different ways. One of the most simple is to inject(<%= %>) value as function argument inside of script tag. Unfortunately this pattern has well known XSS vulnerability but in a little different form than same injection in html template.
We are trying to build a better development workflow by connecting all our tools together.
So, this time we tried to connect HopToad Application with git commits because sometimes it's better to just paste the link to hoptoad error rather than describe all steps to reproduce. This idea was resulted in the command line interface for hoptoad api with a little git integration -
Shelltoad.
When I have to debug ajax requests, I always feel pain in the ass accessing the exception message and backtrace. It require at least 3 clicks to get them and only in the plain html format, that web framework use to generate. Is it better to see it at once in the browser popup?
We used to have less problems with subject and behavior when writing our unit tests. And
context is what testing is all about.
Web apps manage data and the same method can return different values based on current database state.
Advanced rspec features make it possible to use very effective technique to organize tests.
In order to reflect your non-linear business process in unit tests you can not only nest contexts in each other but also make your context more dynamic.
All of us are using passwords and most of us are typing them several times a day. And everyone knows the criteria to generate a good password. Random passwords are very strong from protection point of view but not from usability point of view.
No body think about password unforgettable-ness and less-painful-to-type-ness. I saw many passwords that are very painful because they are just random.
And I think it's nice to lose some randomness and make it easier to type and remember.
There is still a lot of enough strong passwords that match this criteria as well.
Once my co-worker propose an idea to fill database with some fake data because we didn't have a gui forms yet and we have to show something that works to customer. That was a start for great pattern -
populator.
After having a good practice on using
Ultimate rspec matcher to test validation I think it's time to implement one for testing named scopes - custom finders. Testing these finders is daily task. Here is how it can be done with minimum amount of code and maximum readability.
After a first thousand of tests using Rspec I fount it very annoying to repeat my self testing the standard code as spec code is usually twice longer than code it test. I've started to look for a way to simplify the patterns and make it reusable. Among other nice rspec tricks there is possibility to write custom Rspec matchers. Spec the validation is just two lines of code for each attribute now.
REST became the best practice for organizing CRUD server side interface.
But what to do when we have something more than hello-world application that
goes forward from data CRUD and provides many presentations
of the same data with different filters and different layouts?
Designer have used element class attribute for CSS styling for ages. Nowadays classes are also used in javascript selectors. This overlapping cause additional problems: Changes in js may cause broken design and changes in design may cause broken js. The last one may be hard to detect especially when design and css are handled by different person.
