Group Project part 2
Ruby on Rails
Rails is a framework built on Ruby. Simple commands automatically build working software super quickly. The risk of this for developers is the creation of software you don't understand, and potentially not being able to customise the software to your requirements. I've used Devise for user authentication, which gives me confidence the authentication I'm using is pretty robust (compared to writing it from scratch as a non-expert in authentication), but, it quickly becomes hard to see what's going on in your programme, especially when tools hide this information, and making changes to the custom settings is often not easy.
💡 David Wickes's blog explains the danger of frameworks, "The Cake Mix Metaphor for Frameworks"
Change default password settings with Devise
Our spec required passwords to be between 6-10 characters long, globally. This setting can be changed in the
# ==> Configuration for :validatable # Range for password length. config.password_length = 6..10
However, with some simple user testing we found that users who use a password manager will always have passwords suggested which are longer than our character limit (the the standard of suggested passwords by the password manager is consistent), so developers need to be mindful here by finding out why the requirements in this case vary from the norm (there may be a ligitimate reason, the client is the domain expert!).
Customising the accepted password complexity with Devise is more complex as it's not available out of the box. It is possible to add Password Complexity Validations To Devise or to introduce the Devise security extension \o/.
The UK had record breaking heat this week and my train service advised passengers not to travel. The team invited me to join the team sprint planning remotely over Slack, displaying my big ol' face in the meeting room.
I did however spend a lot of the day working solo exploring a new feature, and as I wasn't able to attend the careers workshop I took notes from a podcast, "How Do Tech Companies Read Your Resume".
Tech CVs share a lot of similarities with typical corporate job CVs, such as listing experience in the context of completed accomplishments (as opposed to passive responsibilities), and highlighting your best achievements or successes. It's not typical to submit a fuddy two page CV with a covering letter for tech jobs though, one page CV is effective and pretty standard in the UK.
Be sure to position yourself as the developer you are! Demonstrate your enjoyment of coding and your opinions around code (blogs, open source contributions, and hackathons are great ways to express this).
Make your bootcamp education clear. Prioritise any paid work you've done, your unique side projects, or big projects where you made meaningful contributions. over clones and course projects (and if you must, choose examples with a strong codebase which you contributed heavily towards!).
💡 keywords are for LinkedIn, not your CV!
Whatever you put on your CV, be prepared to talk at length about it. You never know what the person hiring will find interesting!
🐝 bee walk weekend!
🍦 ice-cream retros are fab
🎢 does Rails love feature tests or do feature tests love Rails?
Top comments (0)