• PostgreSQL. Как правильно хранить котов или история одной миграции
    +3

    Про "не будут добавляться" — это хорошо известная сказка :)

  • Стандарты кодирования и другие практики в IT
    0

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

  • Стандарты кодирования и другие практики в IT
    +1

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

  • Стандарты кодирования и другие практики в IT
    +1

    Выскажусь про пример с юнитами. Юнит-тесты — инструмент разработчика. Не в компетенции менеджера запретить писать юнит-тесты. С тем же успехом может запрещать использовать библиотеки или анонимные функции.

  • Быстрое клонирование объектов в JavaScript
    0

    Хорошая новость, т.к. Купертох node-v8-clone забросил. Но бенчмарки и тесты вы оттуда притащили бы все-таки, они очень наглядные, плюс там очень хорошее разбираение того, что можно так скоприровать, и что нельзя.

  • Профессионализм и TDD
    +1
    У нас тут с коллегой возник разговор, кто оптимист, а кто реалист. С одной стороны он надеялся, что использующих TDD будет побольше, я же сказал «Вау, ЦЕЛЫХ 3 человека всегда используеют TDD!». С другой — утверждает, что большая часть людей, проголосовавших за «Тестирую не по TDD», используют ручное тестирование — под отладчиком прогнали, ручками потыкали, и вперед. Я же искренне верю, что это пункт про автотестирование, просто тесты пишутся после кода, а не до.

    Было бы классно разделять такие пункты на «пишу тесты, но не по TDD» и «Тестирую без автоматизации».
  • ES6 в деталях: прокси
    0
    После ruby очень не хватало методов метапрограммирования для создания действительно гибких api. Теперь вот есть надежда, что станет веселее. Конечно, то, что сам инстанс proxy является отдельным объектом, сильно усложняет использование…
  • RPC, Messaging, REST: Терминология
    +5
    REST != CRUD. CRUD — это только паттерн управления ресурсами, а REST — это очень широкий архитектурный подход к проектирования API, который позволяет целиком перенести состояние системы в запрос.
  • Обзор новшеств Docker Engine с 1.0 до 1.7. Введение в Docker Compose
    0
    Упоминается docker-machine — пока beta, но для дев-окружения подойдет отлично. Теперь это официальный способ запускать docker на маках, вместо boot2docker. Плюс они планируют интегрировать эту утилиту с другими компонентами.

    docker-compose любопытный, подъем согласованного кластера Vagrant'ом на маке был не самым тривиальным способом, надо освоить.
  • Все дело не в количестве строк кода. От серийного разработчика модулей
    +4
    Есть одна сложность с кучей модулей — найти в них можно только если знаешь, что искать. У нас в компании-то приватный npm уже разрастается достаточно, что некоторые решения «теряются», и их находят много позже, да и то — только потому, что кто-то знал про него и увидел, что в коде вместо него используется велосипед.

    Я гуглю много мелочей прежде, чем костылить самому, но идея, что можно, например, использовать модуль homedir, мне просто в голову не приходила.
  • Меня беспокоит Agile, и я хочу об этом поговорить
    0
    А почему «заказчик отсутствует как класс»? ГД — и есть точное воплощение product owner'а, который заинтересован в конечном продукте (игре).
  • Ответ на Решетчатое наследование
    +2
    Вопрос навскидку. В каком отношении находятся классы «Квадрат» и «Прямоугольник»?

    Не уверен, что классы «Утка» и подкласс «Утка, умеющая стрелять из ПЗРК», будут соответствовать substitution-принципу. Подкласс сможет поражать цели, что не мог бы делать родительский класс.

    Тут обычно говорят «Use composition instead of inheritace».
  • Обсуждение фильма «Интерстеллар»
    0
    Радиус Шварцшильда для Солнца — всего 3 км. Черная дыра размером с солнце будем иметь массу порядка 500000 солнечных.
  • Дриббблификация дизайнеров
    0
    Окей, действительно — статью прочитал не то что бы совсем по диагонали, но с купюрами — и фраза про «дизайнеры должы писать код» проскочила мимо :) И правда странное предложение. Как UX соотносится с кодом — мне не очень понятно. Задача все-таки гораздо более общая, код — очень низкоуровнево уже. Хотя техническая грамотность дизайнера, конечно, очень желательна, т.к. позволяет экономить на коммуникации.
  • Дриббблификация дизайнеров
    +2
    Да ладно, при чем тут код? Достаточно взять ручку и листочек и четко сформулировать задачу, обозначить контекст, в котором это задача решается (предметная область), выдвинуть идею как решить эту задачу — в случае дизайнера — на уровне UX / UI, словами и набросками.
  • TJ Holowaychuk: Прощай Node.js
    +19
    «Люди довольны» — с одной стороны не сильно аргумент, т.к. до сих пор живут люди, довольные Delphi и Borland C Builder :)

    Все языки/платформы/фреймворки — это инструменты, имеющие свою область применения, а не самоцель. There's no silver bullet. А разработчики все же люди, у них изменяются решаемые задачи, изменяются самые технологии, и в какой-то момент они упираются в те самые рамки области применения для своего инструмента, и многие — кто с огорчением, кто с радостью — берут в руки другой инструмент. Это нормально, так работает прогресс :)
  • Типичные ошибки API платежных систем
    +2
    REST — это не только структура самих URL'ов, но и логика обработки запросов. По REST сервер является stateless, т.е. не хранит состояние между запросами, а все действия — атомарны и самодостаточны. Для обеспечения транзакционности сервер должен быть statefull.
  • DevConf 2014: Разработка крупного масштабируемого web 2.0 проекта с нуля (15 июня, мастер-класс на целый день)
    +1
    А есть такой же, только без крыльев онлайновый? Не только же в Мск такие темы интересны :)
  • Viewaide: теперь и web-сервис
    +1
    Пользуясь случаем, передам привет отличному фотографу Andy Prokh, который является автором КДПВ: снова кот и профиль на photodom :)
  • Введение Стивена Вольфрама в язык Wolfram
    +1
    Хм, что-то туповат видимо, но не очень понял — как и где этот… не сказать, что язык, скорее систему, можно потрогать руками? На www.wolfram.com/language/ ссылка «Start Write your own code» помечена как «Coming Soon». Или пока только на примере Mathematica?
  • Автотесты. А не отдать ли на аутсорс?
    –1
    Ну, насколько незнакомы? :) Можно обеспечить хорошую читаемость, например Cucumber, в который завернуть Capybara.

    Cucumber — по сути генератор тестов на основе простого лексического парсера, можно написать очень понятные обработчики прям на естественном языке. На одной конфе товарищи утверждали, что в такой связке им тест на баг добавил заказчик, который просто нашел косяк в работе сайта. :) Нормально знакомый с IT, но все же.
  • Автотесты. А не отдать ли на аутсорс?
    0
    Хм, простите )
  • Автотесты. А не отдать ли на аутсорс?
    0
    Дубль, простите )
  • Автотесты. А не отдать ли на аутсорс?
    +3
    Идея реально может сыграть для функционального тестирования какого-то внешнего API по принципу черного ящика. Если этот API зафиксирован во времени и его поведение не меняется.

    Юнит-тесты — в первую очередь инструмент для разработчика, а в TDD — так вообще инструмент не столько для тестирования, сколько для проработки интерфейсов внутренних сущностей. У меня в работе часто бывает, что вроде бы минорное изменение несколько изменяет модель, и небольшие изменения веером расходятся в 3-4 сущности, для которых надо соответствующим образом обновить тесты. Если разработчик не работает с тестами — то у него связаны руки для внутреннего рефакторинга. Если работает и правит соответствующие тесты — то непонятно, зачем тогда аутсорс.

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

    Про функциональное тестирование именно GUI на frontend'е не могу сказать чего-то принципиального, я работаю с backend'ом. Но в любом случае тут важным фактором опять же будет изменчивость интерфейса. Сколько будет стоить поменять какую-то структурную единицу приложения, включая переписывание теста? Как часто могут происходить (из вашего опыта) такие изменения? Спустя какое время после того, как разработчик напишет интерфейс, на этот интерфейс будет написан тест? Кстати, как разработчик будет проверять, что все хорошо и он ничего не сломал? 10-20 раз руками после каждого патча кода? Не быстрее ли ему написать тест, и эти 10-20 раз прогонятся в автоматическом режиме?

    Этот пост написан сторонником TDD.
  • Опрос. Как вы делаете деплой на production сервер(а)?
    +1
    Эта фраза не для меня, а для тех, кто думает, будто руби — что-то плохое :)
  • Опрос. Как вы делаете деплой на production сервер(а)?
    +5
    capistrano с обновлением версии из гита + eye

    деплой происходит одной командой cap production deploy

    Хоть оно и на руби, но в целом является аналогом очень продвинутого баш-скрипта, мы используем во всех проектах вне зависимости от языка
  • Несколько применений Sublime Text 3, которыми Вы могли бы пользоваться
    0
    Вам — не знаю :) Я вот регулярно выкатывают новые версии серверов, и надо тут логи посмотреть, там конфиг поправить, подебажить код прямо в работе и т.д.
  • Несколько применений Sublime Text 3, которыми Вы могли бы пользоваться
    0
    Вы можете залогиниться по ssh на удаленный сервер фактически под любой никсовой осью и использовать там ровно те же инструменты, которые используете у себя на десктопе, сохраняя привычное удобство и скорость работы.
  • О чём молчит Joker. Рассказ-история о конференции
    +2
    По словам «jvm scala AOT» уже могу угадывать автора, пока-что работает безотказно :) Никита, спасибо за рассказ. А где будут материалы выкладывать? Я б послушал.
  • Git. Автоматическая проверка сообщения коммита на стороне сервера с помощью Python
    +1
    Менять можно любые коммиты. Каждое изменение — фактически новый коммит, т.к. меняется SHA, ничего страшного.

    Отклонять весь пуш — гораздо логичнее, чем выборочно какие-то коммиты применять, какие-то нет.

    Поменять месседжи 10 последних коммитов просто — git rebase HEAD~10, нужным комитам поставили «edit» вместо «pick», быстро пробежались и все поправили :)
  • Почему я снова комментирую код приложений на Ruby/Rails
    0
    Ха, вы меня поймали, и правда что-то фигню сморозил :)
  • Почему я снова комментирую код приложений на Ruby/Rails
    +1
    На меня в этом плане серьезно повлиял TDD — вот уж где пришлось овладеть принципом «low cohesion, high coupling». Как только встает задача «протестировать одну фичу из всей этой макаронины» — сразу начинаешь все разделять на разные сущности, код логически становится гораздо проще. Меньше shared state, больше явного взаимодействия.
  • Почему я снова комментирую код приложений на Ruby/Rails
    +1
    Да ладно, даже если предположить, что у нас идеальный ревьюер, который никогда не делает глупых ошибков (хотя все люди их делают), то может легко остаться какой-нибудь комментарий в заголовке модуля, где упоминается функционал, или в другом методе, который пользуется этим методом — он просто не попадет в контекст ревью в тако случае
  • Почему я снова комментирую код приложений на Ruby/Rails
    +7
    … что lists — это на самом не lists, а оставшееся от прошлой команды название и модель эта теперь везде в тестах называется Things

    Начнем с того, что переименуем везде lists в things — вот и начали рефакторинг в сторону упрощения кода. И дальше поехали, упрощать, отделять и абстрагировать :)
  • CoffeeScript в примерах. Валидация
    0
    Это не Coffee.

    coffee> if ('required' in rules || str.length > 0) && result == false then true else false
    false
    

    O RLY? Но даже если бы был косяк в синтаксисе — вы игнорите главный тезис, что зачем-то навернули сложности.
    Сейчас она изрядно помолодела, а у нынешнего поколения книжки не в моде. Чтению они предпочитают видео, яркие простые картинки и алкоголь

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

    Материал невысокого качества. Это не повод оправдываться «утилитарностью и воздержанием от перфексионизма» — не бойтесь, он вам не грозит. Что бы не тратить время — пишите хороший код сразу, что вам мешает :) Не можете — тренируйтесь! Как раз на тему книг — вам бы «Совершенный код» и «Рефакторинг. Улучшение существующего кода» прочитать. Они не привязаны к языкам и как крутятся вокруг тем хорошего/плохого/достаточно хорошего кода.
  • CoffeeScript в примерах. Валидация
    0
    По поводу дизайна — не самым лучшим решением преставляется описание правил в виде строки.

    Если кто-то совершит опечатку, то об этом узнаете только при вызове метода. Плюс работа зависит от порядка.

    Если написать правило «required|trim», то оно провалидирует строчку из пустых пробелов — сначала проверит, что длинна строки больше 0, потом отрежет все пробелы и сохранит новое значение. Очевидно, это косяк дизайна. По хорошему сначала должны применяться все морферы (операции, изменяющие строку), только потом делаться валидация, причем очевидно возникают приоритеты в ошибках.

    Для правила «valid_email|required» по хорошему надо в любом случае сначала проверять на required, убедившись, что данные вообще есть, и только потом применять к ним любые другие валидаторы — а у вас первым сработает valid_email и юзер получит ошибку про неправильный email(а не про его обязательность).

    Эти проблемы не вылечить одной строчкой, и что бы решение было общим — надо усложнить структуру объекта и логику работы.

    Скрывать текст можно тегом <spoiler title="...">...</spoiler>:
    Код с комментариями
    Открывается и все показывает
  • CoffeeScript в примерах. Валидация
    0
    Я просто к тому, что это решение на скорую руку — вполне подойдет для решения задачи здесь и сейчас, но вы все-таки статью пишете, которую другие люди будут читать. Мне кажется они заслуживают хорошего продуманого кода. По этой же причине я и говорю про нехватку ООП и OOAD. Как видите, не набрали и десятка плюсов — что как ни это является подтверждением моих слов.

    Про запутанный кусок — мне кажется тут не логика запутанная, а вы ее путаете. Если я правильно понимаю, то вы имели ввиду следующее:
    if result in [true, false]
      if ('required' in rules || str.length > 0) && result == false
        ... # ловим ошибку
    else
      .... # перепишем результат
    
  • CoffeeScript в примерах. Валидация
    0
    Not bad! Хотя я не помню, честно говоря, когда использовал уже эту запись для создания чего-то другого кроме массивов и объектов.
  • CoffeeScript в примерах. Валидация
    +1
    По теме, сугубо из желания сделать мир лучше, субъективное мнение. Статью закончил читать с некоторым разочарованием. Сам по себе пример вполне жизненный, валидация — добро, и не только для форм :) Но исполнение не очень радует.

    К статье:

    Зачем двойной листинг с комментариями? Под кат бы его, он только сбивает с толку свои появлением второй раз, когда уже собрался читать дальше :) Да и когда тебе показывают комментарии в духе "# вернет true, если число больше заданного", невольно начинаешь чувствовать себе идиотом.

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

    validation = new validation
    

    По коду:

    Чем вам так нравятся инверсные условия? Я лично в таким нагромождениях уже не могу с ходу их разобрать:
                unless result in [true,false]
                ...
                # если не просили пустую строку, но ничего не получили
                else unless 'required' not in rules and str.length is 0
                    if result is no
    

    Что, простите? О_о Это не конкурс головоломок, это же код. К слову, комментарий тут под стать коду и тоже ломает мозг(не просили, но не получили...?!). Мне лично кажется, что в этом условии даже есть ошибка. (Правило внесения отрицания под скобки: !(a && b) раскрывается как !a || !b)

    Зачем ошибки отделены от класса в отдельный внешний объект? Это же часть логики класса, хранили бы их в статическом поле класса.

    Почтой валидатор не пропустит мой ящик :) Объект класса назван с маленькой буквы, да и правильнее назвать «Validator» — вроде бы и мелочь, но неопрятно. Еще всякие мелочи бросаются в глаза. Нормальный прототип, но в продакшн в такой виде не пустил бы :)

    Если вы хотите опубликовать цикл примеров — заведите репу на гитхабе, выложите их там рядом со всеми необходимым зависимостями и страничкой-примером, вам спасибо большое только скажут :)

  • CoffeeScript в примерах. Валидация
    +2
    if data isnt off
    

    Воу-воу-воу, меньше наворотов! Если они есть — это не значит, что надо применить все сразу :) «if data»

    if @errors_list is undefined
        @errors_list = {}
    if @errors_list[field] is undefined
        @errors_list[field] = []
    

    Отличные оператор есть ||=
    @errors_list ||= {}
    @errors_list[field] ||= []
    

    Кстати слово list тут лишнее, да еще и неправда, у вас хэш, а не список :)