Очень нравятся подкасты Дмитрия, я уже давно слушаю их. Мои коллеги теперь побаиваются моего кода :))))) потому что там монады :))))) Хотя все мои уверения что это намного понятней, чем городить кучу проверок, не помогают :) Пользуюсь монадами, работают надежно и делают код наглядней. Дмитрий, спасибо Вам за то, что Вы остаетесь с нами и делитесь с Нами своим бесценным опытом!
Можно конечно закрывать глаза на плохой код, но от этого продукт лучше не станет. Придет время когда вносить изменения в него станет просто невозможно из за плохого проектирования.
Заниженная самооценка — это самый деструктивный фактор из всех что есть. Я опробовал его на себе. Никому не советую. Трудно потом выкарабкаться. А чтобы не сомневаться в своей оценке, нужно быть уверенным в себе и своих знаниях. Москва — не сразу строилась :) Не все рождаются Биллами Гейтсами. Так что цените себя за каждую пусть маленькую но удачу!
Если ты стремишься к качеству, ты будешь расти, так как для получения качественного продукта, нужно стремиться к минимизации багов и рисков с ними связанными. Да и еще не всегда проект может интересовать тебя или может быть близок к твоим интерсам, но вот то что ты делаешь должно приносить удовлетворение. Мне очень нравится книга под названием «Идеальный программист» Роберта Мартина. Там очень все довольно ясно объяснено кто есть профессионал. Прочитав его, в себе находишь моменты которые нужно корректировать, чтобы стать настоящим профессионалом.
Вообще ты можешь считать себя хорошим программистом если владеешь технологиями TDD, BDD и DDD. Знаешь и умеешь применять SOLID принципы, понимать что такое KISS, YAGNI, DRY и так далее. Когда результатом твоей работы является качественный продукт и когда заказчик доволен. Вот мне кажется такие вот простые составляющие хорошего программиста. А на каком языке ты программируешь не важно.
Если Вы имеете ввиду пример, то у меня интересовал результат преобразования из coffee-script в javascript. Результаты не вдохновили. В конце концов я указал лишь свое мнение и не более.
Получается что я не могу доверять полностью CoffeeScript. Ибо мне нужно подразумевать, что некие инструкции могут восприниматься не так, как ты того ожидаешь.
Во-первых Вы ошибку допустили в скрипте. У Вас два раза i используется переменная.
Во-вторых я не понимаю почему в офф документации используют именно этот вариант вызова alert
alert j for j in [1..5]
и почему он не работает кода вдруг ниже появляется подобная инструкция со сдвигом?
Вообще честно сказать посмотрев в сторону CoffeeScript понял одно, что пока не готов его использовать. Пусть он упрощает кодирование и меньше кода получается, но вот то, что он выдает в файл .js мягко говоря, конфузит. Пока буду использовать синтаксис старого доброго JavaScript.
Многие люди покидают серьезные компании, руководствуясь собственными амбициями. Когда человек достигает порога знаний, применяемых в организации и не видит дальнейшего развития применяемых
технологий и знаний, он покидает эту компанию. Придя в новую, он сталкивается с проблемами другого рода, не такими как в его компании, иными. Но вот ведь незадача, при возникновении проблем, приходит мысль: — А не ошибся ли я с выбором? И тут встает дилема, вроде как ты крут, ты знаешь технологии и у тебя богатый опыт, в данной ситуации ты можешь диктовать условия, но плодородной почвы мало! Человек привыкший работать в крупных корпорациях, не посмотрит в сторону менее известных и менее величественных. Компании делают величественными — люди. Главной ценностью любой компании, по моему мнению, является коллектив. Коллектив, который стремится поддерживать дружеские отношения, взаимопомощь, стандарты кодирования, управления. Когда каждый из сотрудников стремится внести свою маленькую лепту в улучшение продукта, в отношения в команде, в развитие технологий. Поверьте, есть гении, которые не разлагаются и не дают разлагаться команде или компании в которой они находятся. Такие люди делают очень многое на работе и тот темп, который они задают передается всем и приносит свои плоды. Это стоит больших усилий и работы над собой. Каждый может пробудить в себе такого гения, пускай не в таком масштабе. В таких компаниях приятно работать и в такой компании всегда будет развитие и рост. Из такой компании не будут уходить люди! Стоит расслабиться и любое государство может пасть, не то что там какая-нибудь компания. Легко потерять хороших работников и трудно их вновь вернуть.
Вообще само TDD подразумевает стратегию Test First и если разработчик в процессе написания теста воссоздает необходимый функционал, то он сможет увидеть, какие зависимости или ответственности ему следует отделить, вынести за пределы. Да TDD заставляет дробить объект первоначальной задумки, но в конце концов программист, да и качество продукта, от этого только выигрывает. Этот процесс называется рефакторингом. Который постоянно преследует программиста в процессе воссоздания окончательного варианта модуля. Красная полоса -> рефакторинг -> зеленая полоса. Появляется такая великолепная возможность, как повторное использование. И она достигается, например за счет единичной ответственности класса за какой либо функционал. В конце концов применение DI\IoC контейнеров, которые избавляют разработчиков от надобности плодить фабрики. TDD заставляет по другому посмотреть на тестируемый класс или функционал. Тест дает уверенность программисту в том, что он ничего не поломал, при условии что тест не был подогнан под поведение тестируемого модуля.
К сожалению, заказчик не понимает что такое тесты и зачем они нужны. Он платит за работающий продукт. Тесты нужны прежде всего разработчику. На начальном этапе, тесты тормозят разработку, ведь приходится покрывать функционал на каждом из слоев приложения. Написание теста также избавляет программиста от рутины запуска приложения (если каждый запуск может отбирать часть драгоценного времени, которое могло бы пригодиться для выявления проблем) для тестирования его функционала. Позволяет раздробить точки тестирования приложения и сосредоточиться на определенном функционале, что делает тестирование более эффективным. В любом случае использование TDD в купе с применением принципов ООП, делает продукт успешным, а код совершенным!
Во-вторых я не понимаю почему в офф документации используют именно этот вариант вызова alert
и почему он не работает кода вдруг ниже появляется подобная инструкция со сдвигом?
Содержимое CoffeeScript файла
Выходной javascript скрипт
А я всего лишь хотел чтобы было вот это:
технологий и знаний, он покидает эту компанию. Придя в новую, он сталкивается с проблемами другого рода, не такими как в его компании, иными. Но вот ведь незадача, при возникновении проблем, приходит мысль: — А не ошибся ли я с выбором? И тут встает дилема, вроде как ты крут, ты знаешь технологии и у тебя богатый опыт, в данной ситуации ты можешь диктовать условия, но плодородной почвы мало! Человек привыкший работать в крупных корпорациях, не посмотрит в сторону менее известных и менее величественных. Компании делают величественными — люди. Главной ценностью любой компании, по моему мнению, является коллектив. Коллектив, который стремится поддерживать дружеские отношения, взаимопомощь, стандарты кодирования, управления. Когда каждый из сотрудников стремится внести свою маленькую лепту в улучшение продукта, в отношения в команде, в развитие технологий. Поверьте, есть гении, которые не разлагаются и не дают разлагаться команде или компании в которой они находятся. Такие люди делают очень многое на работе и тот темп, который они задают передается всем и приносит свои плоды. Это стоит больших усилий и работы над собой. Каждый может пробудить в себе такого гения, пускай не в таком масштабе. В таких компаниях приятно работать и в такой компании всегда будет развитие и рост. Из такой компании не будут уходить люди! Стоит расслабиться и любое государство может пасть, не то что там какая-нибудь компания. Легко потерять хороших работников и трудно их вновь вернуть.
К сожалению, заказчик не понимает что такое тесты и зачем они нужны. Он платит за работающий продукт. Тесты нужны прежде всего разработчику. На начальном этапе, тесты тормозят разработку, ведь приходится покрывать функционал на каждом из слоев приложения. Написание теста также избавляет программиста от рутины запуска приложения (если каждый запуск может отбирать часть драгоценного времени, которое могло бы пригодиться для выявления проблем) для тестирования его функционала. Позволяет раздробить точки тестирования приложения и сосредоточиться на определенном функционале, что делает тестирование более эффективным. В любом случае использование TDD в купе с применением принципов ООП, делает продукт успешным, а код совершенным!