Skip to content

Instantly share code, notes, and snippets.

View samnang's full-sized avatar
🚀

Samnang Chhun samnang

🚀
View GitHub Profile
@swlaschin
swlaschin / ndclondon17_fp_track.md
Last active July 10, 2017 11:04
Functional Track talks from NDC London 2017

Functional Track talks from NDC London 2017

Also, here is the list of all videos from NDC London 2017:

Wednesday 2017-01-18

@adeekshith
adeekshith / .git-commit-template.txt
Last active February 21, 2024 12:06 — forked from Linell/.git-commit-template.txt
This commit message template helps you write great commit messages and enforce it across teams.
# <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
@derwiki
derwiki / README.md
Last active September 27, 2023 17:50
Ruby module that you can use in a `before_action` on sensitive controllers for which you'd like a usage audit trail

Adding an audit log to your Rails app

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.

@PurpleBooth
PurpleBooth / README-Template.md
Last active May 3, 2024 18:53
A template to make good README.md

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

@samnang
samnang / clear_logs.rb
Created May 24, 2015 14:02
Clear logs
# 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