Also, here is the list of all videos from NDC London 2017:
# <type>: (If applied, this commit will...) <subject> (Max 50 char) | |
# |<---- Using a Maximum Of 50 Characters ---->| | |
# Explain why this change is being made | |
# |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->| | |
# Provide links or keys to any relevant tickets, articles or other resources | |
# Example: Github issue #23 |
If you have any sort of administrative interface on your web site, you can easily imagine an intruder gaining access and mucking about. How do you know the extent of the damage? Adding an audit log to your app is one quick solution. An audit log should record a few things:
- controller entry points with parameter values
- permanent information about the user, like user_id
- transient information about the user, like IP and user_agent
Using the Rails framework, this is as simple as adding a before_action
to your admin controllers. Here’s a basic version that I’m using in production.
# config/initializers/clear_logs.rb | |
if Rails.env.development? | |
MAX_LOG_SIZE = 2.megabytes | |
logs = File.join(Rails.root, 'log', '*.log') | |
if Dir[logs].any? {|log| File.size?(log).to_i > MAX_LOG_SIZE } | |
$stdout.puts "Runing rake log:clear" | |
`rake log:clear` | |
end | |
end |
#!/usr/bin/env bash | |
# | |
# Rails console script that can be run on AWS Elastic Beanstalk. | |
# | |
# Run this script from the app dir (/var/app/current) as root (sudo script/aws-console) | |
# | |
set -xe | |
EB_SCRIPT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k script_dir) |
I think you might benefit from a detailed study plan when you're a little further along with your studies. For now, I'd recommend following your interests, and taking a project-based approach towards learning.
Start with an idea of something you might want to build, and then make a list of all the stuff you'd need to learn to build it. Then, strip down the idea to make it a little more simple, and redo the list. Keep doing that until you have a list that's small enough to manage
Fair warning: full-scale applications tend to look like "first invent the whole world, then build your app", so you may need to come up with really simple ideas to start on. That's OK! You may also not know what you need to know until you try building things, that's OK too.
Once you have a few ideas, start reading and watching videos related to the technical tools and concepts you need. But only go just as deep into those resources as you need in order to build one small piece of a real project... you can always come back later i
Keep reading and watching videos, but cut that time down in half and use the rest of the time for exploring codebases and writing code of your own. If you do a code reading exercise, make sure you have the code open in your editor, and that you're able to interact with it via a REPL, its tests, etc.
Then from there, I'd recommend starting with very small, tiny projects. Ideally your first one should be something so simple you can do it in an hour or two.
Gradually work your way up from those tiny projects to slightly bigger ones. So start with one that takes an hour or two, then move up to one that might take 5-10 hours, then one that might take 20 hours, then 40 hours, etc. It's OK to stop at the size where you're feeling you're getting the most learning benefit.
Each time you try a new project, make it realistic if you can, but don't worry too much if you'll actually use it. The value is in having a rich context to try out ideas, not in the actual utility of whatever you build.
For each project you wor
# Sources | |
* Cunningham / Beck on CRC | |
* GOOS | |
* Wirfs-Brock + Wilkerson "OO Design, a responsibility driven approach" | |
* Object-oriented brewery | |
---- | |
> What we often do is "procedural programming with objects" or |