Git — сложная штука. Испортить все очень легко, а исправить проблему иногда чертовски сложно. В официальной документации прослеживается проблема курицы и яйца: сложно понять как выйти из сложной ситуации если не знаешь название штуки, которая тебе требуется чтобы исправить проблему.
Вот список плохих ситуаций, в которые я попадала, и как я в итоге смогла выбраться. На простом языке!
Ой, блин, я сделал что-то не то. Тут же есть машина времени, правда?..
git reflog
# ты увидишь список всех действий во всех ветках
# у каждой есть индекс HEAD@{index}
# найди тот, после которого ты все поломал
git reset HEAD@{index}
# волшебная машина времени
Блин! Сделал коммит, но понял, что забыл одну мелочь
# сделай что хотел
git add . # или добавляй файлы по одному
git commit --amend
# теперь измени или оставь старое сообщение коммита
# теперь твой последний коммит включает то новое изменение!
Это перевод статьи Ивана Зареа How I would explain a decade of web development to a time traveler from 2007.
Привет! Надеюсь, тебе нравится наш, новый для тебя мир. Он сильно отличается от мира 2007 года. Если ты только что взял ипотеку, вернись и закрой её. Поверь мне.
Я рад, что тебя всё ещё интересуют компьютеры! Сегодня у нас их гораздо больше, чем 10 лет назад, что принесло новые сложности. Мы носим компьютеры на руках и голове, держим их в карманах, они встроены в холодильники и чайники. Автомобили успешны в самоуправлении, а программы (чему мы их научили) играют лучше, чем люди, почти в каждую игру, за исключением наверно только алкогольных игр.
Изучать современный JavaScript — болезненно, если вы не знакомы с ним с самого его рождения. Экосистема разрастается и меняется с такой скоростью, что сложно разобраться с тем, какие проблемы пытаются решить разные инструменты. Я начал программировать в 1998 году, но к серьёзному изучению JavaScript приступил только в 2014. В то время я помню как анализировал Browserify и изумлённо смотрел на его слоган:
Browserify позволяет запрашивать (require) модули в браузере, объединяя все зависимости.
Можно сказать, я не понимал ни слова в этом предложении, и с трудом осознавал, насколько это может быть полезно мне, как разработчику.
Цель этой статьи — показать исторический контекст развития инструментов JavaScript до их уровня в 2017. Начнём с самых первых моментов и построим шаблон веб-сайта, как бы это сделали динозавры — без инструментов, чистый HTML и JavaScript. Затем мы будем пошагово вводить различные инструменты, чтобы на практике видеть, какие задачи они решают — поочерёдно. Благодаря историческому контексту у вас будет больше возможностей изучить и лучше адаптироваться к бесконечно меняющемуся JavaScript. Давайте начнём!
Это перевод статьи 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) сложнее. Но, по существу, смысл в том, что значение зависит от истории программы. Насколько глубокой истории? В худшем случае (при наличии глобального изменяемого состояния) полной истории, от начала программы. Вам нужно знать всё об исполнении программы, включая то, как чередовались треды.
Григорий Грудинин прошел все 4 проекта на Хекслете и рассказал о своем интересном опыте. Вот его история:
Всем привет! Хочу рассказать о своем опыте прохождения проектов. Сразу оговорюсь, что узнав о таком интересном нововведение, бросил свой почти законченный путь по стеку PHP и окунулся в мир nodejs. Сделал я это только по одной причине: проекты - это самое важное, что даёт этот образовательный ресурс. Можно долго решать какие-то задачки, проходить курсы, без этого никуда, но основной толчок в собственном понимании того, к чему всё это идёт, дают именно проекты. Признаюсь честно, после прохождения курсов по PHP, курсы по nodejs казались гораздо более продуманными, более ориентированными на новичка. Проходил их достаточно быстро (никогда не делал больше 1-2 шагов в день, иначе решение дается очень легко, но в голове ничего не остается), кроме нескольких довольно сложных моментов, на уроки по которым запросто могло уйти несколько дней, а то и неделя.
Первый проект застал меня в сложном положении: в тот момент в первый раз за несколько лет находился в родном городе, пришлось пожертвовать встречами и общением на пользу дела, основную часть писал (и переписывал) почти на границе с Монголией в деревне, пользуясь тормозным интернетом с мобильного телефона...
Подвижка в сторону функционального программирования произошла, признаться честно, около десяти лет назад. Мы заметили, что языки вроде Scala, Clojure, and F# начали привлекать внимание. Это было больше, чем приычный энтузиазм — "О, круто, новый язык!". Было что-то выделявшее его, по крайней мере мы так думали.
Закон Мура обещал нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Этот закон работал с 1960 до 2000. А затем остановился. Вообще. Частота тактовых импульсов достигла 3Гц и перестала подниматься. Скрорость света была достигнута. Сигналы не могли проходить сквозь поверхность чипа настолько быстро, чтобы реализовать более высокие скорости.
Дизайнеры железа изменили стратегию. Чтобы получить большую производительность, они добавили больше процессоров (ядер). Чтобы освободить место для этих ядер, они убрали большую часть кэша и конвейерную архитектуру из чипов. Несмотря на то, что процессоры стали немного медленнее, чем раньше, их стало больше. Производительность увеличилась.
Это перевод статьи Артёма Чистякова "The language of programming", породившей интересные дискуссии на HackerNews и Reddit.
Я помню, как изучал свой первый язык программирования. Мы должны были освоить какой-то из диалектов BASIC в рамках обязательной школьной программы по информатике для второго класса. Скрючившись на своих партах под тусклыми флуоресцентными лампами, мы нетерпеливо поглядывали на жужжащие компьютеры IBM, расставленные вдоль стен душной классной комнаты. Это был 1997 год, Россия. Ни у кого из нас не было домашнего компьютера. На доске в меловых разводах учитель написала:
