$1000
Рама от китайского станка CNC3040, шпиндель на ней же. Механику практический никто не трогал. Вообще раму для данной прошивки можно использовать любую.
Спасибо за фидбек. Пообщаемся еще с нашей travel-практикой, вероятно найдем что-то интересное, о чем мы можем рассказать. О многом не можем, по понятным причинам.
Увы, материалы бывают разные. Где-то больше технических деталей, где-то меньше. Расскажите, о чем хотели бы почитать, и, вполне вероятно, мы найдем реальные примеры и поделимся.
Визуально он его провёл через 38-ю параллель, но бортовая система самолёта определяет кратчайший путь не геометрически. Пилот не видел траекторию, нарисованную Rails-приложением, а сотрудник центра планирования полётов не видел траекторию, выданную бортовой системой. Miscommunication в чистом виде.
Не совсем понимаем, кто и почему так говорит. Наши ребята приехали без всяких заготовок, работали на хакатоне до поздней ночи, а потом еще продолжали из отеля. Преимущество у команды было ровно одно — опыт работы с разными API.
Мы гордимся нашей командой, почему бы не рассказать, как все прошло.
С моей точки зрение изначальное использование POST некорректно, т.к. Ваша операция проверки индпотентна и безопасна, а POST не обладает ни тем ни другим свойством.
Если бы сейчас у меня стояла задача ввода сложной формы, то я бы делал так (опять же сильно зависит от юзкейса):
Сервер предоставляет функции валидации уникальности полей, например GET /users/validation/EmailAvailability/ddd@dd.dd
Мы признаем, что на время заполнения формы данный e-mail может быть кем-то занят, но вероятно этого не велика
Делает обычный пост с повторной валидацией всех полей.
Тестовые случае пишутся после того как были получены и проанализированы требования, т. е. параллельно процессу разработки. Сложность тест-кейсов зависит от того, какой функционал они покрывают.
Требования предоставляются заказчиком исходя из потребностей бизнеса, а тест-кейсы уже непосредственно покрывают эти требования. На одно требование может быть написано несколько тестовых случаев.
Всем, кто считает, что ежедневные релизы — стресс, скажу уверенно «нет». Работа в таком проекте очень интересная, т. к. все развивается очень стремительно. К этой модели разработки мы пришли не сразу, переход был длительным и трудоемким, но успешным. Заказчик доволен, а это в нашем деле очень важно.
Есть транковые окружения, на которых идет процесс разработки. Скажем, их версия — 0.200, тогда версия бранча — 0.199. Т. к. релиз каждый день, и каждую ночь от транка отрезается бранч, изменения, которые были в транке, будут в бранче, т. е. версия транка будет уже 0.201, а бранча — 0.200. Чтобы скрыть код для неготового функционала, нужен конфигурационный флаг. По сути, на момент релиза какой-либо фичи код уже находится в продакшн, просто он скрыт.
Мой опыт говорит о том, что все-таки не столько же, и распространенные оценки 1/2 — 1/4 — более-менее отражают реальность. Но your mileage may vary, все очень сильно зависит от типа проекта, фазы, выбранных технологий.
Спасибо за комментарий. В этот раз все докладчики действительно были из DataArt. В Воронеже достаточно компаний с опытными и отлично выступающими джавистами, просто в этом году так получилось. В прошлые годы докладчики были из самых разных компаний.
Презентациями поделимся, как только они станут доступны.
Большое спасибо за вопрос. Действительно, продвижением технических идей и продуктов на рынки, как правило, занимаются специально подготовленные люди: маркетологи, PR-специалисты, лобисты и др., в их арсенале — разнообразные методы, описанию которых посвящены целые книги. И я совершенно согласен, что бизнесу, как правило, технические идеи не интересны сами по себе.
Вместе с тем, я часто сталкиваюсь с переживаниями и фрустрацией инженеров и проджект-менеджеров, которые уверены, что внедрение новой технологии или методики в их проекте принесет много пользы, но не могут донести это до заказчика.
Вот именно для инженеров и проджект-менеджеров (а не для специалистов) написана эта статья. Цель ее — описать базовый подход продвижения технической идеи в проекте. Я думаю, что от этого выиграют и инженеры, и заказчики (бизнес).
Спасибо за комментарий. wp_nonce упомянуто вот тут:
>> Существует функция check_ajax_referer, которая проверяет реферера (проверяет, откуда произошел запрос) и прерывает выполнение, если реферер какой-то «не такой». Эта функция умеет также проверять nonce. Подробнее можно почитать в соответствующей статье кодекса.
Сначала собирался подробно расписать о применении wp_nonce, но потом решил, что статья, все-таки, про AJAX а не про возможные способы защиты AJAX-бэкенда и ограничился упоминанием предназначенной для этого функции check_ajax_referer (даже оставил ссылку для интересующихся)
А вообще Всяческие number-at-once и контрольные суммы в AJAX-запросах в контексте WP — это тема, достойная отдельной статьи. Если есть интерес — в свободное время с удовольствием напишу/расскажу об этом ;-)
Рама от китайского станка CNC3040, шпиндель на ней же. Механику практический никто не трогал. Вообще раму для данной прошивки можно использовать любую.
Мы гордимся нашей командой, почему бы не рассказать, как все прошло.
Если бы сейчас у меня стояла задача ввода сложной формы, то я бы делал так (опять же сильно зависит от юзкейса):
Требования предоставляются заказчиком исходя из потребностей бизнеса, а тест-кейсы уже непосредственно покрывают эти требования. На одно требование может быть написано несколько тестовых случаев.
Презентациями поделимся, как только они станут доступны.
Вместе с тем, я часто сталкиваюсь с переживаниями и фрустрацией инженеров и проджект-менеджеров, которые уверены, что внедрение новой технологии или методики в их проекте принесет много пользы, но не могут донести это до заказчика.
Вот именно для инженеров и проджект-менеджеров (а не для специалистов) написана эта статья. Цель ее — описать базовый подход продвижения технической идеи в проекте. Я думаю, что от этого выиграют и инженеры, и заказчики (бизнес).
>> Существует функция check_ajax_referer, которая проверяет реферера (проверяет, откуда произошел запрос) и прерывает выполнение, если реферер какой-то «не такой». Эта функция умеет также проверять nonce. Подробнее можно почитать в соответствующей статье кодекса.
Сначала собирался подробно расписать о применении wp_nonce, но потом решил, что статья, все-таки, про AJAX а не про возможные способы защиты AJAX-бэкенда и ограничился упоминанием предназначенной для этого функции check_ajax_referer (даже оставил ссылку для интересующихся)
А вообще Всяческие number-at-once и контрольные суммы в AJAX-запросах в контексте WP — это тема, достойная отдельной статьи. Если есть интерес — в свободное время с удовольствием напишу/расскажу об этом ;-)