Пустые директории в git репозитории

Недавно появился вопрос для обсуждения как хранить структуру проекта в git репозитории если речь идет о пустых директориях.

Цель: сохранение целостности проекта, а так же недопущение появления ошибок в случае если нет проверки на созданную папку и создание ее в коде, но она там подразумевает быть, а файлы внутри папки в репозитории не должны находиться (например логи или другие runtime данные).

Проблема: git не будет хранить пустые директории в репозитории. Git вообще не хранит папки во внутренней структуре, он хранит только файлы (FAQ Git kernel).

Какие есть выходы из положения:

  1. Самое очевидное – не хранить пустые директории в репозитории, всегда делать проверку на созданную папку и создавать ее из кода при необходимости.
    • Плюсы:
    • Не имеем вообще вышеозначенных проблем. Никаких лишних папок в репозитории, .gitignore всегда выглядит чисто и там только необходимые пути. Всегда уверены что будет сделана проверка на создание папки.
    • Минусы:
    • На практике скорее всего окажется, что проверка на наличие директории не была сделана, или используется сторонняя библиотека, где это не сделано и все упадет с ошибкой. При взгляде на репозиторий не всегда будет очевидно где храниться runtime/логи и прочее.
  2. Держать всю подобную структуру в файле .gitignore в корне проекта. Указывать там все директории внутри которых необходимо игнорировать все файлы, а в исключение (через !) добавлять файлы .gitkeep находящиеся внутри наших пустых директорий.
    • Плюсы:
    • В таком режиме имеем всю необходимую структуру проекта внутри одного файла, если разработчик увидит что его файл игнорируется, он всегда может пойти в четко обозначенное место для проверки почему это происходит.
    • Минусы:
    • При таком подходе файл .gitignore может немного разрастись, он может выглядеть не всегда очевидно, а так же получаем бессмысленные файлы .gitkeep раскиданные по проекту. Возникает неудобство например если вам нужно сохранить папки внутри директории в которой игнорируется все, для этого нужно будет плясать с ручными указаниями внутри .gitignore.
  3. В глобальном файле .gitignore указывать только игнорируемые глобально по проекту пути. Если же необходимо сохранить определенную директорию мы создаем внутри нее еще один файл .gitignore и внутри него игнорировать все кроме .gitignore
    • Плюсы:
    • Убиваем двух зайцев: создавая внутри пустой директории файл и в нем же указывая игнор внутри этой папки.
    • Минусы:
    • Имеем неясную структуру игнорирования проекта раскиданную по всем директориям, а не в едином корневом .gitignore файле. Кто то может глобально переписать такое использование .gitignore.

В интернете если различные доводы на эту тему, но в целом однозначной best practice найти не удалось:

Собственно мое мнение совпадает вместе с последним автором, в связи с чем считаю проблему статьи решенной.

Jun 4   git   it   programming

Дорога до работы в метро

Почему людей так напрягает длительная дорога до работы на метро?

Когда начинаешь спрашивать, что конкретно вам не нравится или как бы вы провели эти 2 часа вашей жизни, конкретный ответ редко услышишь.
Порой дома очень много времени уходит на разную ерунду, вроде рутинных дел, общения с домашними, просто тупняка, я уж молчу про тех кто смотрит телевизор. В метро вы в изолированной среде, в которой количество возможных действий ограничено, это дает определенное преимущество узкого выбора действий.

По моему это как раз отличное время чтобы заняться чем то полезным:

  1. Первое что сразу же приходит на ум это конечно же книги, часто ли мы читаем дома? В метро это идеально заходит. Если вы тратите на дорогу около 2 часов в день, это примерно 30-40 часов чтения в месяц, по моему это сделает любого человека лучше, читать конечно тоже надо правильные книги, а не мусор. Ну и лучше читать электронную книжку, бумажные книги очень часто доставляют дискомфорт в метро своим размером, особенно огромная техническая литература.
  2. Длинные видео конференции, скринкасты, вебинары, видеокурсы. Тоже отличные занятия. Очень часто на часовые видео дома или на работе просто нет времени, и плейлист на youtube “watch later” заполняется длинными видео с конференций, за обедом выбор падает в сторону коротких видеороликов или сериалов. В метро как раз идеальное кол-во времени для ознакомления с вышеуказанным плейлистом.
  3. Подкасты. Редко когда подкасты можно назвать чем то совсем полезным, это все таки скорее развлечение, я лично предпочитаю слушать их когда я куда то иду, но в целом в метро тоже идеально ложится их обычно часовой формат.
  4. Онлайн курсы. Сейчас появилось много платформ для обучения, которые предоставляют свои приложения, из русскоязычных например stepic.org дает очень удобный способ учиться с портативных устройств:
    https://itunes.apple.com/ru/app/stepic.org/id1064581926
    https://play.google.com/store/apps/details?id=org.stepic.droid
    Так же хорошие приложения у Coursera:
    https://itunes.apple.com/app/apple-store/id736535961?mt=8
    http://play.google.com/store/apps/details?id=org.coursera.android
    И у CodeSchool (правда доступно только видео):
    https://itunes.apple.com/us/app/code-school/id927194858?mt=8
    А так же приложение от Apple iTunes U для обучения с большой подборкой курсов:
    https://itunes.apple.com/ru/app/itunes-u/id490217893?mt=8
2017   study   thoughts

Как я стал программистом

Целая тьма подобных статей появляется постоянно, пришла и моя очередь написать одну. Не сочтите за пафос, программистов миллион и я уж точно не какой то особенный, это просто история.

Однажды на одной из работ я столкнулся с очень банальной задачей – нужно было автоматизировать несколько простых задач (обработка данных, выгрузка на сервер и прочее), для этого начальник вручил мне книжку по Unix, и посоветовал ознакомиться с разделом по bash. Думаю именно в этот день моя жизнь сильно изменилась.

Все мои работы всегда были очень странными, я с самого раннего детства увлекался компьютерами и всегда работал только в этой сфере, начинал с техподдержки, в которой пробыл почти 5 или 6 лет, работал вроде как администратором серверов, банковских систем еще много чего, но работа почти всегда состояла из какой то магии, словно я был не специалистом в какой то определенной области, а безумным машинистом случайно дергающим рычаги, очень долгое время мне было просто все равно где работать, я не чувствовал особо себя удовлетворенным, но деньги всегда платили хорошие, так что я как то вроде плыл по течению.

Как только в вышеуказанный день я столкнулся с каким то подобием программирования (конечно же с удовольствием написав свою первую программу автоматизации на bash) я почувствовал что меня начинает безумно тянуть к этой сфере, вместо того чтобы работать я начал штудировать форумы, различные сайты и выяснять, что же можно программировать, как все это работает и как собственно попасть в эту сферу. В начале все казалось безумно сложным и не понятным. В какой то момент я наткнулся на подкасты (Радио-Т и DevZen были моими первыми) и меня окончательно и бесповоротно унесло, когда я слышал что то про разработку, про сферу, про людей, про процессы программирования меня накрывало какой то непонятной волной счастья и честно говоря не отпускает до сих пор. С этого момента я поставил себе цель стать разработчиком.

В начале меня очень привлекала идея обучиться и стать фрилансером, мне виделось это гораздо более простым вариантом, чем найти работу (от части так и есть), с английским у меня все в порядке, с навыками коммуникации и общения с людьми вроде тоже, продать себя смогу. Кстати вот нашел свою тему на тостере более годовой давности :)

Далее начались поиски способов обучения, за это время я пробовал кучу разных сайтов по обучению программирования, помню как мой друг отговорил меня от оплаты подписки сервиса GeekBrains, на котором если не ошибаюсь я хотел купить курс на год (ужасная идея), далее был пройден htmlacdemy, что то на CodeAcademy и еще по чуть чуть на разных сайтах, понимание не приходило и работа занимала кучу времени, на обучение оставалось совсем не много, а в совокупности с неверными методами это не приносило плодов. Очень часто казалось что ничего не получится, часто думалось о возрасте (мне 28 лет было), типа “может уже поздно что то менять?” Вообщем полный восторг сменялся упадком. Кстати я сделал еще одну странную вещь, когда увлекся программированием – купил макбук, хоть сейчас конечно же я об этом не жалею, это мой рабочий повседневный инструмент, но кто знает как могло все сложиться и это скорее было веянием хайпа, можно было остаться и на линуксе.

В какой то момент, сейчас уже точно не помню как, я набрел на один не очень примечательный ресурс, у него не было рекламы во всех щелях рунета и ярких лендингов – hexlet.io. В этот момент моя жизнь развернулась еще раз, и наверное этот раз был самым важным.

Начал я знакомство с ним с вебинаров, где какой то умный дядька рассказывал супер сложные вещи, говорил о каких то космических книгах в которых я вообще ничего не понимал, но почему то эта подача была настолько крутой, открытой и интересной, что очень хотелось разобраться. Потихоньку я начал осваиваться на ресурсе, стал проходить первые бесплатные курсы по PHP и даже немного читать слак сообщество. Наверное в жизни каждого человека были люди, которые очень сильно влияли на их судьбу и разворачивали сознание в другую сторону, в моей жизни такими стали мои учителя математики в школе, мой отец и упомянутый выше человек, по имени Кирилл, за что ему отдельное спасибо. На хекслете есть еще один человек, которого тоже нельзя не упомянуть, это Рахим, его философски-технические подкасты и размышления тоже очень сильно на меня повиляли. В целом дополню, что одной из причин, чем мне так нравится эта индустрия это ее тусовка: сообщества, встречи, очень мудрые люди и настоящие звезды, это круто следить за всем этим, а быть частью еще приятнее.

В это время я окончательно понял что программирования это та вещь, которой я хочу посвятить остаток своей жизни и решил сделать ход конем. Я накопил определенную сумму денег и решил плотно заняться обучением. В это же время моя девушка уезжала на семестр в португальский университет и я укатил на 90 дней (шенген макс) в Лиссабон вместе с ней. Шли дни и недели под палящим португальским солнцем, я зарывался в дебри разработки, иногда было супер сложно, иногда так сложно что невыносимо хотелось бросить, но в конечном итоге всегда решение задач приносило невообразимое удовольствие. Примерно через пару месяцев на хекслете запустили шикарную услугу “Проекты”, о них подробнее я уже писал в своем блоге чуть раньше, суть в том что они дали к очень хорошей теоретической базе сильную практику и тут как раз все сложилось как надо и начало потихоньку приходить понимание. Примерно в это же время я осознал, что хочу офисную работу, с возможностью пообщаться с коллегами, работой в команде и так далее, так что изначальную идею о фрилансе решил пока спрятать в ящик.

После прохождения проектов и возвращению в Россию я начал потихоньку искать работу, так как я уже влился в сообщество, мне очень много помогали с резюме (отдельное спасибо Веронике за ее посты и советы). Сами собеседования на удивление очень отличались от всего что было со мной ранее, а на интервью я был очень много раз за жизнь. Основное что отличалось это “удаленность”, почти всегда это был либо онлайн тест, либо какое задание на день или несколько. За все время по телефону я общался 1 раз, и то это был недостойный работодатель, который предложил приехать, а на собеседовании предложил совсем другую должность. В целом меня, как любителя цифрового асинхронного общения такая ситуация более чем радовала. В конце концов я нашел очень маленькую компанию, скорее похожую на семейный бизнес, с отличным коллективом, который решился меня взять. На самом интервью, как мне кажется, я отчасти удивил многими знаниями, которых не ожидают услышать от новичка.

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

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

Напоследок дам краткий ликбез как бы я начал изучать разработку сейчас:

  1. В начале как можно меньше времени тратить на чтение “мнений” вроде того какие языки лучше, разных статистик по рабочим местам, зарплатам и прочей чепухи (я на это убил огромное кол-во времени)
  2. Изучить базовые концепции программирования, не вникая особо в специфику языков, библиотек, фреймворков
  3. Изучить связанные с областью вашей будущей специализации технологии (например для веб разработки то как работают сети, серверную составляющую, базы данных, HTML)
  4. Изучить специфику платформ и особенности языков программирования с которыми планируйте работать
  5. Начать изучать инструментарий, библиотеки, фреймворки и параллельно начинать искать работу

Параллельно с этим как можно больше писать код, решать искусственные сложные задачи, стараться писать или хотя бы разбирать реальные проекты, вступить в какое то сообщество или найти ментора, слушать подкасты, читать твиттер, блоги, интересоваться сообществом и обязательно читать книги (еще я много читал статей, например на хабре, но сейчас уже не уверен в их полезности, так что на любителя).

Ну и самое главное никак не относящееся к программированию, никогда не переставайте искать себя, поверьте, это стоит того чтобы найти.

2017   hexlet   it   programming   study   work

Hexlet projects. part 3.

Пишу немного с задержкой, неделю назад завершился третий проект на hexlet. На этот раз была затронута такая тема как асинхронное программирование.
Сразу оговорюсь, что мне лично эта тема дается очень тяжело, но я стараюсь разобраться.
В курсе асинхронщина проходилась в лучших традициях хекслета, начиная с самых основ и по пути рефакторинга. Вначале все началось с callback функций, которые просто откровенно выносят мозг, как только программа становится более менее сложной, далее идет рассмотрение более современных способов, решающих проблему асинхронного выполнения – промисы и в самом конце настоящее спасение – async/await.
Суть проекта была в построении CLI утилиты, которая скачивает веб страницу с вложенными линками, которые указаны в тегах, а так же меняет ссылки в этих самых тегах на локальные. Вначале я использовал promises для асинхронного кода (чтение данных, загрузка из сети), после того как понял что мое приложение развило слишком высокую сложность и с промисами очень сложно отслеживать ошибки и вообще следить за flow, я переписал все на async/await, что значительно упростило работу с кодом и само приложение. В проекте очень много использовалось стандартных модулей node.js – fs, url, os, path, что дало возможность ближе познакомиться с ними и изучить их возможности. Еще хочу отметить данное видео от Филипа Робертса, оно очень сильно помогло мне разобраться с асинхронным флоу. Тем у кого возникают трудности с этим, маст хев. Ну и у него отличный сайт, где можно поиграться с работой любого кода и визуально посмотреть на стек вызовов.
В целом как и ранее проект очень сильно помог мне разобраться в определенной предметной области, но этот проект отличался тем, что очень сильно вымотал, не знаю почему именно, видимо это особенность асинхронного программирования :) Итоги как всегда в GitHub.

На этом основные проекты закончились и я потихоньку начинаю заниматься поисками работы, параллельно заканчивая курс hexlet, в нем уже остались более прикладные вещи (реализация http server, микрофреймворк js express и др.). Так же еще будет 4 проект, что то вроде дипломного, стартует 6 марта и на этот раз будет длится 2 недели, но он будет состоять из 1 шага, скорее всего это будет чисто прикладной проект, но вероятнее всего будет работа с БД, что очень радует.

2017   hexlet   it   programming   study

Сложности в понимании основ, part 1.

к данной статье стоит относиться с осторожностью, писалась совсем новичком

Во время изучения программирования, возникает очень много ступоров при понимании различных концепций, решил агрегировать список понятий, которые мне даются с трудом и попытаться их объяснить.
Прежде всего для хорошего понимания любого кода, который был связан с данными понятиями мне очень пригодилась Подстановочная модель вычислений, которая опирается на Стратегию вычисления конкретной среды.
Каррирование функций – концепция пришедшая из функциональных языков программирования, позволяет частичную передачу аргументов функции, то есть не одновременно несколько аргументов, а как бы по очереди. При декларировании функции например в js мы при этом каждый раз возвращаем анонимную функцию, которая принимает следующий аргумент. В понимании этого мне очень помогла вот эта статья, там на примерах разбирается подробное понимание этого понятия.
Вот пример каррирования функций для самодельной реализации If, true, false:

const If = (bool) => bool;
const True = (x) => (y) => x;
const False = (x) => (y) => y;

If(True)('good')('bad'); // good
If(False)('good')('bad'); // bad

По сути функция просто выбирает первый или второй аргумент в зависимости от переданной функции. Данный пример вводит еще два понятия, они не так сложны в понимании, но упомянуть стоит.
Функция высшего порядка и Функции первого класса (лямбда функции) – ФВП это функция, которая может в качестве аргумента принимать и другие функции (так как в js все функции являются объектами первого рода, то по сути это любая функция в js), ну а ФПК это какая либо анонимная функция(не именованная), записанная в переменную для передачи в качестве аргумента.
Рекурсивный и итеративный процессы, реализованные через рекурсию – написанное выглядит как полнейший бред, но на самом деле это вполне реальные концепции, так же имеющие место быть при функциональном стиле программирования. О различиях этих процессов есть просто великолепная заметка. В целом для себя я обозначил прежде всего то, что рекурсия это вызов самого себя(к примеру функции), но уже как реализовать подход вычисления при вызове самого себя это как раз и есть данные процессы. Рекурсивный процесс начинает вначале разворачивать вашу рекурсию и как только она будет развернута до конца начинает вычисление значений (отложенное вычисление). Итеративный же процесс занимается вычислением значений на каждом шаге рекурсии (для этого используется отдельная переменная – аккумулятор). По ссылке выше есть отличные примеры в виде факториала.

Чуть позже вернусь с Замыканием и Концепциями ООП

2017   it   js   programming   study

Hexlet projects. part 2.

Итак на hexlet позавчера завершился второй проект, решил отписать отзыв по нему тоже. Что это, и как проходила первая часть писал чуть выше.
Во втором проекте уже подготовка окружения и прочее отдавались на самостоятельную настройку, первое что немного испугало в начале, это решение писать это приложение через tdd. Вкратце, суть методологии в написании тестов перед кодом, главная цель этого в том, что вы должны четко представлять интерфейсы, которые хотите разрабатывать еще перед тем как начать писать их. Скажу, что tdd оказался просто шикарной техникой, он совершенно по-другому позволяет думать в рамках кода, когда ты уже знаешь как будешь это использовать.
Само приложение – это простая версия юниксовой утилиты diff, предназначенная для сравнения двух конфигурационных файлов (поддержка .json, .ini, .yaml).
В самом начале мы реализовывали плоскую структуру сравнения, что было относительно не сложной задачей (поизучал паттерн проектирования “адаптер” и отличную библиотеку lodash, которая дает просто уйму маленьких, но очень полезных функций по работе с разными структурами данных, по ней есть неплохая статья, а так же разные парсеры используемых форматов). Но вот когда мы перешли к файлам с вложенной структурой и выборке форматов вывода, вот тут началось настоящее испытание, на одном из шагов застрял практически на 2 суток.
Переосмысливая проблемы возникшие передо мной, я сейчас понимаю, что очень тяжело дается построение правильных абстракций в моем приложении. К примеру вначале у меня была функция, которая получает данные, сравнивает и сразу же делает из них готовый вывод, что в случае нашей задачи, не верно.
В конечном итоге, как только я разделил сравнение данных (тут пришлось поглубже поработать с ast-деревом, программа представляет внутренние данные после сравнения именно в нем) вывод стало намного проще. При выборке форматов вывода, познакомился с паттерном стратегия.
Классов в моем приложении по прежнему нет, хотя кое что можно было реализовать через них, но не обязательно.
В целом проект в очередной раз дал многократный толчок в моем понимании “проектирования архитектуры” приложений, как я по прежнему это называю, ну и тут еще больше пригодилась помощь ментора, которым вновь выступал Кирилл, за что ему огромное спасибо. Конечный результат в репозитории.
Кстати количество проектов сократилось до 3, после чего будет что то вроде дипломной работы, следующий стартует 13/02, после чего вернусь с ощущениями.

2017   hexlet   it   programming   study

Hexlet projects. part 1.

О чем это

На моем любимом портале по изучению программирования hexlet появился новый тарифный план включающий в себя “проекты” в рамках одной из профессий Бэкенд JS-программист.
Недолго поразмыслив я решил перейти на этот тарифный план (120$ в месяц), так как мне нужен реальный опыт разработки проектов + это формирует портфолио, так как весь код идет на github.
Проекты состоят из 5 уровней, каждый из которых будет доступен по прохождению части курсов, перерывы между проектами 2 недели. Сам проект с дедлайном и длится 7 дней. Вчера закрыл 1 уровень и решил написать отзыв.

Окружение

Первые несколько этапов состояли из корректной настройки окружения, а также формирования корректной структуры проекта. Это были действительно очень полезные знания, специфика разработки на JS не так проста, поэтому приобретенные навыки я думаю пригодиться мне везде в дальнейшем пути и на будущей работе.
Во время подготовки к проекту разобрался с Vagrant (на виртуалке которого собственно вначале тестил этот блог). Очень хочется еще разобраться с Ansible для написания playbook-ов с конфигурациями, но так как в целом мое локальное окружение (OS X) позволяло мне адекватно работать и без виртуалок решил отложить, чуть позже пройду курс на том же hexlet.
В рамках первых частей проекта я изучил:

  • git – я думал что знаю что то про git, но когда начинаешь сталкиваться с реальной работой оказывается знаний недостаточно, так что неплохо разобрался в разных мелких проблемах возникающих при стандартных операциях работы с git. Парочка полезных статей, которые пригодились: раз и два
  • npm – так как npm сейчас является стандартом де факто в JS и в бекэнд и во фронтэнд разработке при работе с модулями, то эти знания тоже очень полезны, наконец то научился работать с package.json (раньше всегда в ручную ставил пакеты) – оказался очень функциональный файл. А так же опубликовал свой первый пакет в npm. Полезные статьи для работы с npm: раз и два. Еще очень полезным было понимание разницы между devDependencies и dependencies.
  • Make – совершенным открытием стало использование утилиты Make для различных действий, которые никак не связаны с компиляцией, очень мощный инструмент. Если бы раньше знал о нем, много вещей упростил во время работы в администрировании. Вот видео раскрывающее тайны :)
  • Travis – шикарный инструмент для автоматизации тестирования и деплоя вашего кода, работает непосредственно с гитхаб, а всю статистику можно увидеть прямо в браузере. В рамках проекта мы цепляли к нему только eslint, но в любом случае знакомство состоялось.
  • babel – инструмент без которого в js никуда, тоже раньше не работал с ним, научился настраивать и подключать его к коду. Babel это транспайлер современного EСMA в понятный для текущей версии интерпретатора синтаксис (node.js или например браузер)
  • eslint – eslint я уже пользовался, но кое что новое все же узнал, например о .eslintignore, настройкой путем YAML файла конфигурации, а так же совместной работой с babel.
  • code climate – интересный инструмент, проводящий автоматизированные код-ревью (работает с github репозиториями)
  • Flow – очень мощный инструмент, с которым до конца еще не разобрался, занимается проверкой типизации вашего кода, умеет либо просто находить ошибки типов или работать в более расширенном режиме flowtyped где вы вручную можете указывать типы данным.

Точка входа

После знакомства с инструментарием и настройкой окружения мы приступили непосредственно к написанию кода. Можно было задавать вопросы в специальных формах в разделе проектов на сайте (как приватные вопросы ментору по каждому шагу так и общие, на которые могут ответить другие участники проектов), а так же активное общение шло в нашем слаке. Ментор на проект только один, в данном случае это был создатель проекта Кирилл, очень старался помогать всем и со всем, но возможно не всегда хватало времени и возможности ответить всем, так как потом вопросов и пул реквестов валился очень большой. С одной стороны в начале не хватало какого то личного наставника с которым например по скайпу или в привате общаешься, но немного подумав позже я понял что это скорее плюс нежели минус, потому что умение разбираться с проблемами самому – очень нужный навык, особенно для разработчика.
Сами задачи на первый взгляд были не очень сложными (ведь все это я уже делал, думал я), но когда ты начинаешь делать это не в рамках курсов, а просто с нуля сам, это совсем другие ощущения, так как “навыков проектирования” (не уверен в верной формулировке, но для себя это назвал так) нету совсем в итоге сидишь и думаешь с какого конца подступиться.

Кочки и камни

В итоге первый блин кода был конечно же комом, так как я утыкал все условными конструкциями и циклами, что конечно даже я понимал ужасно. Ментор развернул меня и направил мой взор в сторону функций, тут уже пошло получше. Цель была написать простенькую игру с заданными условиями. После выполнения задачи начался второй этап, где нужно было написать похожую игру но с другими условиями и необходимо было выделить каркас игры отдельно в index.js файл, а сами игры должны были быть отдельными модулями, которые формировали свои условия. Вот тут начался полный тупняк. Так еще сложилось что я писал все это сидя на чемоданах в Лиссбоне в Cтарбаксе, почти целый день у меня ушел на переписывания моей первой части и доведения до ума всей этой концепции единого каркаса. Дальше еще три игры я дописывал в аэропорту, в самолете и на временной квартире в Москве – ощущения незабываемые :)
Но зато в голове стойко закрепились мысли о том где нужно делать определения функций, а где вызовы, что нельзя городить кучу внутренних вложений функций, а определять их плоско в рамках модуля, о бинарниках, которые совершенно не должны касаться кода, а лишь являются исполняемыми файлами с необходимым импортом, и еще много полезных дырок в основах, закрытых в рамках разбирательств.

to be continued

В итоге у меня получился вот такой репозиторий c 57 коммитами и 15 пулреквестами. Мой код еще очень далек от идеала, но он точно намного лучше чем то что я написал вначале, огромное спасибо hexlet и конкретно Кириллу за это. Буду с нетерпением ждать 2 уровня проектов (который начинается 23 января) и отпишу новый отзыв по нему. Единственное что немного пугает во 2 уровне, что вроде как проверка уже будет автоматизированной, а не ручной и боюсь не увидеть много своих ошибок, надеюсь этот вопрос будет как то решен.

2017   hexlet   it   programming   study

First step

Приветственное слово

Давно было желание завести подобную страничку где можно складировать накопившиеся в голове мысли или выкладывать полезные статьи. Послезавтра наступает Новый год, чем не повод начать что то новое.
У меня нет определенной тематики о которой я хотел бы писать, но в целом скорее всего будут посты про IT индустрию, возможно что то смогу добавить про путешествия.
В данный момент в моей жизни происходит довольно много интересных событий – я пытаюсь сменить карьерный вектор в сторону программирования. В целом в IT индустрии я работаю довольно давно, но почему то только лет в 28 понял что хочу в будущем заниматься программированием всю оставшуюся жизнь. Сейчас активно занимаюсь самообучением и развитием в этой области. Последние 3 месяца проживал в солнечном Лиссабоне после увольнения с работы, а 6 января уже 2017 года возвращаюсь в Москву где и планирую потихоньку начать искать работу уже разработчика.

О создании блога

Кстати на данный движок наткнулся случайно, сначала хотел поднимать WordPress и кастомизировать его. Но в твиттере подвернулся пост о движке Эгея, написан он на PHP небезызвестным Ильей Бирманом, блог и твиттер которого, я с удовольствием читаю. Хотя в движке закрыт доступ к кору его можно кое как кастомизировать, добавлять блоки, можно переписать тему, в дальнейшем планирую этим заняться. Хотя это всего лишь тестирование, возможно потом перееду на что то более кастомное. Пока же привлекло очень быстрое разворачивание (установка) движка на сервер.
В начале тестово поднял на виртуалке, а потом сделал это на сервисе vscale.io, где как раз кстати у меня давно валяется 400р бонусов. Все что требуется для работы адекватный PHP, пара модулей, apache (или nginx) и mySQL с созданной базой. Все это ставиться очень быстро и просто, в качестве ОС взял свежую Ubuntu 16.04.

При разворачивании на сервере проблем не было, единственное были проблемы на локальной машине, когда разворачивал через Vagrant и делал синхронизацию локальной папки и корневой директории Apache на виртуалке, дело в том что движку нужны права на запись в папки для создания .htaccess, а Vagrant не дает вам править эти права вручную.
Это легко решается правкой Vagrantfile:

config.vm.synced_folder "guarblog", "/var/www/html",
owner: "vagrant",
group: "www-data",
mount_options: ["dmode=775,fmode=664"]

Ссылки, которыми пользовался для справки:

2016   it