Родители айтишников рассказывают об их работе, репортаж об опыте арендного жилья ПВТ, критика функционального программирования и золотые правила программирования в NASA, а также подборка англоязычных подкастов для программистов — в ссылкообзоре за прошлую неделю.
Родители айтишников рассказывают об их работе, репортаж об опыте арендного жилья ПВТ, критика функционального программирования и золотые правила программирования в NASA, а также подборка англоязычных подкастов для программистов — в ссылкообзоре за прошлую неделю.
Репортаж о том, как живётся в новых домах: жизнь в квартирах которые достались айтишникам из Парка высоких технологий.
В современных арендных домах нынче всё деловито и современно:
Если кто-то и надумает сверлить, то, извиняясь, предупреждает об этом в общем чате Skype — там более двухсот жильцов.
В комментариях море скепсиса:
Статья в радужных тонах написана. С высокой долей оптимизма так сказать. Но в принципе и нужно радоваться за людей. Жаль немного не дошли до частной собственности. Зашли бы посмотрели, как умеют люди жить в домах 41 и 41А, и как не надо жить и относиться к своему дому в доме 39А.Только не 16-го числа. Там по плану хоть плохонькая, но состоится уборка, которая проходит аж раз в месяц.
Уточки в маленьком пруду это конечно здорово смотрится на фото, вот только жаль, не развиваете тему о том, что пруд-то планируют засыпать и натыкать на его месте и рядом со школой высоток, вместо планировавшегося ранее парка. Лучше бы конечно магазин… Но квадратные метры пользуются и в кризис спросом.
Российский Microsoft в своем блоге проводит разбор технических моментов устройства одного местного белорусского стартапа: KUKU.io — как устроен облачный сервис для управления социальными сетями. Благо для этого есть хороший повод — сервис хостится на Microsoft Azure.
KUKU.io дважды попадал на Product Hunt, победил в конкурсе стартапов Bel.biz Battle и IE Venture Day, а также занимал высокие места и участвовал в ряде крупных международных форумов. В сентябре мы едем представлять проект на Pirate Summit, и тоже надеемся, что проект высоко оценят.
KUKU.io bird is growing! pic.twitter.com/xa85H9cvau
— KUKU.io (@kukupost) June 16, 2016
Очень приятно, что в последнее время всё чаще поднимается тема улучшения качества нашего образования. В том числе анализируются вопросы возможных улучшений и с позиции их потенциальной пользы для отечественного ИТ.
Як развіваць беларускую адукацыю? Галоўныя адмыслоўцы краіны расказваюць, на што хворая беларуская адукацыя і як яе выратаваць. Школьныя адукацыйныя праграмы надзвычай састарэлыя, ўрокі інфарматыкі абмяжоўваюцца толькі вывучэннем Microsoft Office і асноваў Pascal. Гэтая практыкі варта інтэграваць і ў беларускія школы. Праграмаванне дае дзецям не толькі магчымасць лепш кіраваць тэхналогіямі, прасцей атрымліваць працу ў ІТ, але таксама фармуе сістэмнае мысленне ў вучняў.
Антон Сідараў, трэнер курсаў праграмавання для дзяцей, расказвае, як дзеці вучацца праграмаваць робатаў, чаму нам трэба павучыцца ў Фінляндыі і якія ўрокі трэба дадаць у школьную праграму.
Свежие интервью с интересными людьми:
Беженцы из #TheDAO и #Ethereum продолжают прибывать на станцию #Bitcoin. Не очень хотелось бы, но выбора нет. #биткоин #криптовалюты #yugos
— YugoS (@yugosobolev) June 18, 2016
Вот это прямо из дурного фантастического романа. Виталика Бутерина маленько жалко: https://t.co/fXLTYAdUyr
— Pavel Kushelev (@pqorama) June 18, 2016
Функциональное программирование непопулярно, потому что оно странное.
Приведу достаточно большой и примирительный к критике комментарий из-под материала:
Да блин, хватит упарываться уже. К чему эта сугубая религиозность: ФП, ООП, это все мелочи. ФП и ООП это всего лишь инструменты для построения абстракции. Мы ж не спорим чо круче пила или молоток. ФП — небольшие функции для обработки состояния без сохранения состояния. ООП — хранение состояния системы во время всего жизненного цикла. Зачем противопоставлять эти концепции? Они ж взаимодополняют друг друга?
ФП всего лишь говорит вам — не хотите неопределенного поведения — уберите сайд-эффекты. Это не значит, что их не должно быть, просто они должны жить отдельно. Отделяйте операции над данными от самих данных. Я для себя выработал следующий подход: Обработка данных — класс, который через конструктор принимает объект с состоянием.
class NumericOperation {
NumberState state;
NumericOperation(this.state);
add() {
return state.a + state.b;
}
}
class NumberState {
int a;
int b;
}
Таким образом, всё состояние, над которым мы производим операции, можно протестировать, потому что мы его задаём только в конструкторе. Легко пользоваться моками. И да, несмотря на то, что NumericOperation хранит ссылку на состояние это не мешает нам писать в ФП стиле. Ведь функция add — чистая.
Для того, чтобы поддерживать систему и дальше, даже если она будет очень сложной — используйте Dependency Injection. Таким образом, вы не будете сами инстанцировать классы, вы будете только указывать каким образом это сделать и какие зависимости должны быть прокинуты. Так можно расширять контракт без потери обратной совместимости на уровне входных данных. Мы не должны зависеть от атомарных типов. Мы должны зависеть от абстракций.Таким образом, мы можем добавить ещё несколько состояний, при этом даже не нарушив внешний контракт при условии, что мы возвращаем корректно значение:
class NumericOperation {
NumberState state;
StringState stringState;
NumericOperation(this.state, this.stringState);
add() {
return state.a + state.b + parseToInt(stringState.c);
}
parseToInt(String c) {
// логика парсинга
return someNumber;
}
}
В качестве полезного напутствия критикам, здесь же приведу ссылку на знаменитое письмо Дейкстры: почему обучение программированию нужно обязательно начинать с функционального языка.
Довольно интересный текст в том плане, что предпринята попытка создать стандартное и последовательное пошаговое руководство новичка Linux по настройке его сетевой безопасности при самоличной установке сервера — Первые 10 минут на сервере.
В комментариях звучит порция конструктивной критики:
Заведение одного пользователя на всех — странная практика — я такое видел только в коллективах конца 90-х типа «разработчики сидят на Windows 98», им выдали загадочный и очень редкий «сервер», с которыми никто обращаться не умеет, лучше на него вообще не дышать, единственный что-то знающий человек («гуру-админ») приходит раз в неделю. Все остальные дружно учат PHP2 или 3 и пытаются делать какие-то сайты. По современным реалиям я не вижу никаких аргументов в пользу того, чтобы не заводить отдельного пользователя на каждого человека: и управление этим всем куда более вменяемое, и аудит безопасности проще и прозрачнее — куда проще понять, кто, что и когда делал.
Фильтрация по IP — опять же, в большинстве случаев бред из эры середины-конца 90-х, когда действительно были какие-то фиксированные IP по организациям и люди сидели и работали строго с работы. По современным понятиям куда администраторам лучше иметь доступ к серверам из любой точки мира (с wifi из кафе), и если что-то случается — иметь возможность зайти и принять меры.
Да если уж на то пошло — в целом любые разговоры о сетях — будь то «зафильтрую по IP», «органичу по VLANу» и т. д. — упираются в то, что бесполезно тупо следовать таким «советам» из «статей» — вопрос об архитектуре сети компании в целом, зонировании, организации каких-то слоев управления, менеджмента сетей, VPNов и т. д. Это весьма комплексный вопрос и крайне наивно думать, что «зафильтрую по IP» что-то решит. В лучшем случае — не решит, в худшем — создаст (зачастую еще хорошо припятанные и оттого больнее бьющие) грабли тем, кому с этим придется работать потом.
Опять же — прописывать вручную фильтр по IP одновременно и в iptables, и в sshd — отнюдь не мера безопасности, а очередная глупость, которая аукнется тогда, когда в следующий раз IP поменяется и очередной админ, которому это «досталось в наследство» сообразит поменять его в первом месте и забудет про второе. Как только одно и то же надо прописывать в нескольких местах — это первый и значительный признак того, что нужно откладывать все эти ручные разборки и нужна уже хоть какая-то автоматизация и configuration management.
ФИАС для администратора сети https://t.co/JE7Ir5BwVj #habr
— Sergey Kotelnikov (@KotelnikovSerg) June 18, 2016
10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками.
В комментариях сетуют:
Некоторые вещи в статике не протестируешь.
У Европейского космического агентства была крутая новая ракета Cluster. Там даже было горячее резервирование системы управления ракетой — но и оно не спасло от необработанного exception. Обе ноды синхронно упали.
Эта неудача входит в список самых дорогих ошибок программистов.
Кроме того в комментариях также нравоучительно добавляют, что согласно официальных данных, NASA имела бюджет в $1,000 на одну строку кода (что в нынешних ценах можно смело умножать на 3).
[Перевод] Когда программные продукты общаются с нами, должны ли они быть дружелюбными https://t.co/DfvUXlxGku #habr
— Sergey Kotelnikov (@KotelnikovSerg) June 18, 2016
Слабое место многих отечественных айтишников — отсутствие навыка восприятия живой английской технической речи на слух. Если добавить сюда отсутствие свободного времени для соответствующей тренировки, то это и вовсе может показаться безнадёжным. Идеальный выход в такой ситуации — подкасты на английском, которые совмещают всё воедино. Вот свежая подборка из 11 популярных подкастов на английском языке специализированных на обсуждении программирования или ИТ.
*Мнение колумнистов может не совпадать с позицией редакции.
**В цитировании сохранены авторская орфография и пунктуация.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.