I would start by installing the Sublime Package Control manager. This tool will allow you to install the other plugins without having to clone git repositories and copying them to the correct folders. Instead you will the command drop-down menu with "Ctrl + Shift + P" and then scrolling down until you see "Package Control: Install Package". A search bar will pop up and you can type the name of a package, click on the name and it will self install. If you have problems setting any of these up email me at barnes7td@gmail.com
Sublime Package Control - Install this first. This tool will allow you to easily install most (if not all) the other plugins in this list. (Ctrl + Shift + P, then select Package Control: Install Package)
SublimeERB - This plugin auto creates the erb tags. (<% %>, <%= %>, etc.) (Ctrl +
Originally published in June 2008
When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.
To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.
Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.
People
 :bowtie: |
😄 :smile: |
😆 :laughing: |
|---|---|---|
😊 :blush: |
😃 :smiley: |
:relaxed: |
😏 :smirk: |
😍 :heart_eyes: |
😘 :kissing_heart: |
😚 :kissing_closed_eyes: |
😳 :flushed: |
😌 :relieved: |
😆 :satisfied: |
😁 :grin: |
😉 :wink: |
😜 :stuck_out_tongue_winking_eye: |
😝 :stuck_out_tongue_closed_eyes: |
😀 :grinning: |
😗 :kissing: |
😙 :kissing_smiling_eyes: |
😛 :stuck_out_tongue: |
| # Логирование | |
| Это есть первая задача, которой я занялся, делая этот сервер. | |
| Причина? Просто я солидарен с этим мнением: | |
| > Я твердо уверен, что внедрить логирование в уже готовую программу без изменения архитектуры приложения – невозможно . | |
| > Точнее внедрить можно, но тогда лог будет настолько страшным и неудобочитаемым, что остается посочувствовать | |
| > тем администраторам, которые будут с ним работать.[1] |
| # Compiled source # | |
| ################### | |
| *.com | |
| *.class | |
| *.dll | |
| *.exe | |
| *.o | |
| *.so | |
| # Packages # |
| function load_dictionary(filename) | |
| local dictionary = {} | |
| for line in io.lines(filename) do | |
| if line:match("^%l%l+$") then | |
| insert(dictionary, line .. "$") | |
| end | |
| end | |
| -- We're cutting all single-letter words, but |
Английская версия: https://evilmartians.com/chronicles/bootstrap-an-intervention
У CSS есть несколько базовых проблем, которые позволяют очень быстро отстрелить себе ногу при неправильном использовании:
Глобальный неймспейс – в серверном программировании все что написано в файле, в файле и остается. Все же что написано в css и js засирает глобальное пространство имен со всеми вытекающими. В JS эту проблему сейчас побороли всякими модульными системами, а вот с css сложнее. В идеальном мире это должен починить Shadow DOM и настоящие Web Components, но пока их нет единственный способ с этим бороться – следовать какой-то системе именований селекторов, которая по возможности уменьшает и исключает возможные конфликты.
Каскадность – если на один элемент может сработать несколько правил, то они все и сработают последовательно. Если есть элемент h1.title, на него сработают все правила для тегов h1 и все правила для класса .title. Так как весь html состоит из тегов, то правил которые п
Markdown - это облегчённый язык разметки, который преобразует текст в структурированный HTML. Следующее руководство поможет вам разобраться, как использовать Markdown.
# Заголовок первого уровня
## Заголовок второго уровня
### Заголовок третьего уровня
#### Заголовок четвёртого уровня
##### Заголовок пятого уровня
| .git | |
| .gitignore | |
| /doc | |
| .yardoc | |
| coverage | |
| jsdoc | |
| /tmp | |
| /log | |
| Dockerfile | |
| Dockerfile.prod |