Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (contributing) open source проекты на GitHub. Одна из причин крутости open source — в желании людей помогать друг другу.
В начале публикация своей работы на GitHub пугает. Существует мало руководств, посвященных этикету, практическим приёмам и ожиданиям. Этот гайд направлен заполнить пробелы.
Это перевод статьи Climbing the infinite ladder of abstraction от Алексис Кинг.
Я начала программировать ещё в начальной школе.
Тогда меня сильно впечатляла идея автоматизации. Я ненавидела выполнять одинаковые повторяющиеся действия раз за разом, и всегда стремилась найти способ решения коренной задачи. Когда я узнала о программировании, меня оно мгновенно зацепило: было так легко превращать повторяющиеся задачи в автоматизированные цепочки процессов, что освобождало меня от выполнения одинаковых, тупых, обременяющих упражнений навсегда.
Чтение чужого кода — один из основных навыков у современного программиста. Несмотря на это, не все умеют читать код, а многим разработчикам не очень нравится этот процесс. Какой-то код читать очень скучно, а другой — просто вызывает желание пойти напиться. Иногда у вас появляются неприятные ощущения от того, что вы не можете его понять или от того, что он просто недостаточно хорошо написан. Большинство разработчиков предпочитает писать код, а не читать, не осознавая того, что чтение — тоже важный навык. Подробно рассказываем, как прокачать навык чтения исходного кода и что это дает.
Специалисты Facebook обнаружили, что их боты общаются на новом языке. И остановили их.
Боб: “I can can I I everything else.”
Элис: “Balls have zero to me to me to me to me to me to me to me to me to.”
Для всех нас этот диалог выглядит как бред. Но что, если я скажу вам, что этот бред — общение, возможно, самого технически сложного коммуникативного софта на всей планете? Коммуникативный софт, который обучался и развивался, чтобы достичь лучшего результата с большей скоростью и производительностью, на которые я или вы когда либо были способны, и возможно, со скрытыми способностями? И это правда.
Этот разговор произошел между двумя агентами искусственного интеллекта (ИИ), разработанными компанией Facebook. Изначально они переговаривались друг с другом на английском. Но позже инженеры поняли, что ошиблись, программируя их.
«Не было никакого смысла придерживаться английского», — говорит Дхрув Батра, инженер Georgia Tech из Facebook AI Research (FAIR). Учитывая то, что эти два агента конкурировали за лучший результат — это такая высокоэффективная схватка ИИ против ИИ — инженеры модифицировали «генеративно-состязательную сеть», и ни у одного из ботов не стало стимула общаться как люди. Поэтому они стали отклоняться от нормы и смешивать реальные слова в кажущиеся бессмысленными предложения.
«Агенты будут отклоняться от понятного языка и изобретать кодовые слова для себя», — говорит Батра, высказываясь в пользу уже предсказуемого явления, которое встречается тут, тут, и тут. «Как если бы я сказал «оно» пять раз, а вы бы поняли, что мне нужны пять копий определённого предмета. Это не сильно отличается от того, как сообщества людей придумывают сокращённые понятия».
Одно из самых проблемных мест в программировании — mutable state — изменяемое состояние. Оно делает код сложным, и как только вы ввязались в него, всё со временем становится более запутанным. Сокращение глобального изменяемого состояния в программе — один из лучших способов повысить качество кода, независимо от того процедурный он или функциональный.
Global mutable state содержит в себе три слова, каждое из которых имеет важное значение:
Global — значит доступный из любого места кода. Таким способом весь код связан. Необходимо рассуждать о взаимодействии всех частей программы, а не её маленьком фрагменте, потому что любая другая часть может касаться этого фрагмента.
Mutable — означает изменяемый (в русскоязычной среде часто говорят «мутабельный», — прим. ред.). Часто можно заметить: все, что может прочитать значение, может так же и изменить его. Два считывания данных, следующих одно за другим, могут возвращать разные значения. Или, что еще хуже, сами возвращаемые структуры данных изменяются после чтения.
Дать определение состоянию (State) сложнее. Но, по существу, смысл в том, что значение зависит от истории программы. Насколько глубокой истории? В худшем случае (при наличии глобального изменяемого состояния) полной истории, от начала программы. Вам нужно знать всё об исполнении программы, включая то, как чередовались треды.
В начале карьеры высоки шансы, что вас наймут исключительно за "профессиональные навыки" — те, что напрямую релевантны вашей специализации. Когда вы свеженький специалист или уже пару лет работаете в своей сфере, то — каким софтом вы владеете, какие знания вы приобрели за время практики, в школе и всякие технические сертификаты имеют большое значение.
Чего вам никто прямо не говорит, это — да, наняли вас за специфические навыки, но их важность постепенно угасает. Чем дальше вы продвигаетесь в карьере, тем меньше вас ценят за эти самые качества, а это особенно важно в середине карьеры. Почему? Потому что повышают вас благодаря другим навыкам.
Иногда престижность работы программиста ломается коллегой, который разбивает голову о клавиатуру. Инновации позволяют программистам быть более производительными, писать код быстрее и качественней. Но это не мешает существовать тем продуктам, которые усложняют нашу работу...
Как разработчик, вы ежедневно возвращаетесь к набору тех проблем, которыми пропитан ваш софт. Он абсолютно всё делает неправильно. А того, что люди от него хотят, этот софт как раз не делает.
Все ваши взаимодействия с пользователями сводятся к тому, что они хотят чего-то, чего вы им не дали. Они не понимают, почему всё не так просто, как им кажется.
Мы мечтаем о том дне, когда кто-то поблагодарит нас за безупречную работу в проекте и не потребует каких-нибудь "добавок".
Спецификации и требования — заранее, пожалуйста!
Возможно, подруге вашей мамы нужна помощь с принтером — ей сказали, что вы работаете в ИТ. Или у вашего продакт-менеджера отсутствуют какие-либо технические знания, и он совершенно не разбирается в современных методах программирования.
Множество исследований связали длительное обездвиженное сидячее положение с диабетом, гипертензией, некоторыми типами рака (особенно у женщин), тревожными расстройствами и в целом более высокой вероятностью ранней смерти. Так же существует риск синдрома плоской спины (выравнивания поясничного изгиба позвоночника). Не удивительно, что всё больше людей ставят экраны компьютеров выше, чтобы работать стоя. Но тренды специфических столов не обязательно сохраняются надолго. Все исследования об опасности сидячего образа жизни содержат противоречивые доказательства, что это не настолько плохо. И помогают ли высокие столы — предмет споров.
Интернет по первому же запросу предоставит вам 1000 и одну рекомендацию, как их писать и формулировать. Увы, обычно на одну рекомендацию даже от лучших ресурсов приходится количество воды, равное объёму олимпийского бассейна. Так что мы поговорим о самых общих, обязательных и полезных вещах, включение которых в сопроводительное точно не повредит.
Вы можете недостаточно хорошо вычитать резюме, но сопроводительное, не важно, на hh или отправленное на почту компании, должно быть вычитано идеально. Избегайте ошибок, поставьте красивые кавычки и тире вместо дефисов, или просто поставьте раскладку Бирмана и пишите красиво всегда.
Подсказка: Вычитайте резюме на предмет таких странностей, как «умею “гуглить”», - в умении ничего плохого нет, а вот в этих кавычках вверху - есть. Или Google как название компании и поисковика, или гугл как нарицательное для источника знаний и ответов на вопросы, забудьте про остальные вариации, не заключайте название компаний в кавычки, если речь не идет об ООО “Рога и копыта”. Если просто: у любой компании есть имя “по документам” (ООО “Рога и копыта”), и есть имя для печати и разговорной речи (Предприятие рогокопытных). Давно вы слышали, чтобы в разговоре без обсуждения документов название компании сочеталось с ООО? То-то же.
Персонализируйте. Обращаетесь вы к компании или к известному вам лицу, которое её представляет, сделайте письмо нацеленным именно на них и ни на кого больше. Даже одно предложение, подставленное в шаблонное сопроводительное, может всё перевернуть.
Зачем? Привлеките внимание, покажите заинтересованность в работе именно в этой команде и банальную внимательность к деталям, которая в IT никогда не бывает лишней. Заодно повысите число ответов и качество фидбэка, так как отношение HR’а может стать более личным.
Подвижка в сторону функционального программирования произошла, признаться честно, около десяти лет назад. Мы заметили, что языки вроде Scala, Clojure, and F# начали привлекать внимание. Это было больше, чем приычный энтузиазм — "О, круто, новый язык!". Было что-то выделявшее его, по крайней мере мы так думали.
Закон Мура обещал нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Этот закон работал с 1960 до 2000. А затем остановился. Вообще. Частота тактовых импульсов достигла 3Гц и перестала подниматься. Скрорость света была достигнута. Сигналы не могли проходить сквозь поверхность чипа настолько быстро, чтобы реализовать более высокие скорости.
Дизайнеры железа изменили стратегию. Чтобы получить большую производительность, они добавили больше процессоров (ядер). Чтобы освободить место для этих ядер, они убрали большую часть кэша и конвейерную архитектуру из чипов. Несмотря на то, что процессоры стали немного медленнее, чем раньше, их стало больше. Производительность увеличилась.
У нас накопилось чуть-чуть новостей и решили еще раз собрать все вместе и поделиться. Вот что мы на Хекслете сделали за июль:
Наконец-то у нас вышел новый курс по Git (можно смотреть бесплатно)
Проекты были только на JS, и нас давно просили запилить проекты по PHP. Так вот, оно свершилось. Первый проект уже запущен, люди проходят, прокачиваются и пишут приятные отзывы.
Некоторое время назад мы вместе с одним из учеников решили провести эксперимент. У него ситуация с обучением мягко говоря непростая. И Кирилл взял его обучение под свой контроль.
Ему 30 лет. Начал учиться с полного нуля. Ни в математике, ни в информатике знаний практически не было. Он до мозга костей гуманитарий и специалист в теологии. Тяжелая физическая работа в ночные смены, семья, ребенок, в общем, время на учебу крайне ограничено.
Work-Life balance — важный термин и концепция, они используются для описания баланса, который необходим каждому человеку между работой и личной жизнью. Подробно рассказываем, как с work-life balance у программистов, и зачем вообще держать баланс между работой и остальной жизнью.
Многие из нас не достаточно хорошо натасканы улавливать намеки, интерпретировать ваши истории как набор действий или читать между строк, чтобы понять, что вы имеете в виду. Извините. Неявно коммуницировать в технических вопросах означает напрашиваться на неприятности. Если вы размазано просите чего хотите, с большей вероятностью вы этого не получите.
Это перевод статьи "The bad reasons you’re forced to work long hours" от Itamar Turner-Trauring.
Работать сверхурочно — непродуктивно, нехорошо для здоровья и, к сожалению, широко распространено. Я настойчиво верю, что короткий рабочий день полезен вам и вашему начальнику, но многие компании и менеджмент заставляют вас работать дольше даже если это снижает продуктивность.
Так почему они это делают? Давайте разберём несколько причин.
Некоторые менеджеры просто не понимают, что работать слишком долго — контрпродуктивно. Возьмём, к примеру, основателей стартапов. Они любят свою работу: стартап – их ребёнок, и они счастливы беспрерывно работать, чтобы гарантировано добиться успеха. Это может быть неэффективным и контрпродуктивным, но они могут этого не осознавать.
Продолжаем серию статей о карьере. В этот раз поговорим о том, как объективно вычислить, на какую зарплату вы можете претендовать.
Начинаем серию статей, посвященных трудоустройству. Как составить хорошее резюме, как вести себя на собеседовании и как понравиться HR-у, нужно ли выполнять гигантское тестовое задание и другие мега-полезные вещи. Все статьи составлены из материалов Вероники Ильиной, опытного HR-специалиста. Вероника уже долгое время неутомимо отвечает на вопросы в канале hexlet-review нашего слак-чата, а еще у нее есть отличный канал в телеграм HR отвечает. Поэтому все заметки - это ответы на реальные вопросы участников слак-чата Хекслета и подписчиков Вероники в телеграм. В первой статье все, что касается резюме программиста. Опытные программисты, конечно, могут и не найти здесь ничего нового, а новичкам обязательно к прочтению.
Это перевод статьи Артёма Чистякова "The language of programming", породившей интересные дискуссии на HackerNews и Reddit.
Я помню, как изучал свой первый язык программирования. Мы должны были освоить какой-то из диалектов BASIC в рамках обязательной школьной программы по информатике для второго класса. Скрючившись на своих партах под тусклыми флуоресцентными лампами, мы нетерпеливо поглядывали на жужжащие компьютеры IBM, расставленные вдоль стен душной классной комнаты. Это был 1997 год, Россия. Ни у кого из нас не было домашнего компьютера. На доске в меловых разводах учитель написала:
SCREEN 15, 0
PSET (100, 100)
DRAW "R20 D20 L20 U20"
END
Многие люди обращаются к нам с одним и тем же вопросом: “А не поздно ли мне становиться разработчиком в X лет?”, этот же вопрос часто встречается на форумах, тостере и подобных сервисах. Часто почему-то “переломным” возрастом является именно 30. Вроде как люди думают, что в 28 еще все ок, а в 30 уже все, пиши пропало. Постарался ответить максимально подробно и честно, на своем опыте и опыте студентов Хекслета.
Спойлер для тех, кому лень читать дальше: стать программистом можно в любом возрасте. В 30 лет - не поздно!
Перевели для вас небольшой пост со StackExchange, в котором юзер под ником Etherable делится историей о своей нелегкой кодерской жизни.
«Сейчас я работаю в компании, где очень много легаси-кода. Система на самом деле очень старая, и хотя меня нанимали как программиста, по сути моя работа это самый обычный ввод данных. В итоге, я получаю набор требований, который по сути является просто массой таблиц с данными по месяцам, которые я должен внести в систему и заставить все это работать. И в целом это решается кучей SQL скриптов.
Многие люди, приходя на работу в новую компанию, сталкиваются с тем, что им не нравится сложившаяся инженерная культура. Люди годами работают так, как они работают, привыкли и им вполне удобно. Чаще всего они скептически относятся к предложениям изменений.