Блог

Прочитал сегодня заметку о том, что программирование скоро исчезнет (https://medium.com/@dtauerbach/software-engineers-will-be-obsolete-by-2060-2a214fdf9737), и даже названа примерная дата – 2060-й год. Ну да, к этому году я скорей всего уже не доживу, чтобы подтвердить эту теорию, но все же, попробую ее опровергнуть уже сейчас. Рассмотрим несколько основополагающих принципов заметки. 

To be sure, software is becoming more efficient, in that sophisticated frameworks have been developed so that fewer lines of source code have to be written, and advanced programming languages, compilers and interpreters have made the life of the programmer much easier than it had been in the 1980s or 1990s.

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

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

Больше всего меня бесят различные теги или операторы в языках программирования и фреймворках, которые автоматически генерируют HTML для форм и их параметров. Я пытался использовать подобные вещи в Microsoft MVC, но не понял выводы. 

Какой преимущество у Html.BeginForm по сравнению с простым классическим тегом <form>. У второго точно одно преимущество есть - нужно меньше нажатий клавиш, чтобы напечатать тэг. 

Я слышал разные попытки объяснить чем генераторы лучше, но если честно, так и не увидел ничего, чтобы я сказал: "Да, это круть, это стоит гемора с необходимостью печатать больше символов". 

Давно хотел попробовать парное программирование и сейчас у меня почти получилось. Я занимаюсь не парным, а удаленным программированием. 

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

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

Давно уже хотел купить себе git хранилище, и даже завёл себе аккаунт на Bitbucket, но почему-то я им так и не пользовался. Я залил туда один репозиторий с CyD Network Utilities, но так и не использовал его. Сегодня я решил этот репозиторий удалить. 

Судя по ценам, Bitbucket вполне приемлем. На нем бесплатно можно получить репозиторий, которым смогут пользоваться до 5 человек. Приятно. А ведь 5-ю аккаунтами может реально пользоваться 100 человек, так что ограничений почти нет :). 

На github цены на много выше, тут бесплатно можно получить только открытый репозиторий. За личные репозитории придётся хорошо платить, за пять личных хранилищ кода придётся отдавать 7 американских долларов в месяц. Дороговато. 

Есть такие установщики для WAMP (Windows Apache MySQL PHP) или MAMP (Mac Apache MySQL PHP), которые запустил, и они ставят что-то на локальную систему, что упрощает конфигурирование локального Web сервера, базы данных и PHP. Создание нового сайта для локальной разработки потом сводится к простому вводу домена для сайта, выбору директории и клику мышкой. Все остальное пакет берет на себя. 

Я когда-то пользовался такими вещами, сам использовал программу MAMP локально. Ну действительно, на много проще. 

Только вот рабочие сервера не будут работать на подобной программе, там уже точно будут ставить LAMP с репозитория и каждый по отдельности. Если программисты могут писать локально сайт на Маке, то на реальном сервере он скорей всего будет крутится на Linux виртуалке, так уж исторически повелось. Запускать PHP сайты на Windows сервера немного расточительно. Не вижу смысла тратить так деньги. 

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

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

Как у тебя относятся к тестам? Забивают или делают юнит тестирование / ручное тестирование? 

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

Да, конечно же я использую Dependency Injection. Без этого писать юнит тесты проблематично, особенно, если приходится работать с Web сервисами. Как раз из-за них я впервые много лет назад я познакомился с этим патерном. Так что достаточно много приходится использовать интерфейсы и инъекцию.

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

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

#тикет 5677 пофиксил херню

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

Блин, ну у вас же есть TFS и в нем можно посмотреть изменения. Неужели там нельзя узнать, кто изменил строку и для какого комита? Если этого нельзя сделать, то зачем вы вообще используете TFS? 

В очередной раз получил вопрос о том, какой язык выбрать. Я из получаю регулярно, но тут автор письма спросил конкретно - C# или Java. 

Выбирай тот язык, который больше нравится, потому что по обоим пока работу найти достаточно легко кажется в любой стране. Если не знаешь, какой нравится, попробуй оба. Снова не решил? Выбирай тот, который сейчас нужен и востребован в твоём регионе, по крайней мере на твой взгляд. 

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

Когда-то давным давно мне в журнале Хакер дали задание написать про SOAP. Я начал исследование и меня поразило, как же сложно все описывают эту тему. Большое количество заумных слов, особенно в статьях от IBM. Я попытался максимально упростить тогда свою статью про Web сервисы и SOAP, но сейчас я решил ещё раз вернуться к этой теме и ещё раз попробовать описать Web сервисы, так сказать много лет спустя. 

Что такое SOAP? Это сокращение расшифровывается как Simple Object Access Protocol, что на великий и могучий язык можно повести как Простой Протокол Доступа к Объектам. И он действительно простой. 

Если читать документацию IBM по сервисам, то там обязательно будут заумные вещи типа общей шины, какая-то ещё херня, но все это просто заумные слова, потому что на самом деле Web сервисы очень простые в использовании. 

Запрос к Web сервису в самом простом случае поставляет из себя банальный HTTP запрос, с таким же заголовком и с такими же параметрами, как и у любого другого запроса к любым другим страницам сайта. У Microsoft сервисы могут работать по TCP для увеличения скорости, но это отдельная история, потому что сейчас мы затрагиваем SOAP – классику, с которой кажется и начинались все эти веб сервисы.