Electron — система позволяющая создавать кроссплатформенные приложения используя одни только веб-технологии, такие как HTML, CSS и конечно, JS.

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

Нет, «Хабрахабр» не умирает. Его не убьёт никакое падение посещаемости, ни угрозы органов власти, ни даже разделение.

Единственное, что ему угрожает — это сами мы.

Disclaimer. Этот пост — развёрнутый ответ на пост Хабр умирает?.

В исходном посте я дал ссылку на свою дискуссию с deniskin от ноября 2014 года (чуть позднее точки на графике ТС, когда Хабр начал умирать): habrahabr.ru/post/278325/#comment_8789143

В том треде я довольно подробно описал, что же произошло с Хабром и почему он умирает. Прошло полтора года, уважаемое сообщество может оценить, кто из нас оказался прав.

Исходный тезис звучит следующим образом: Хабр убило прежде всего непонимание Тематическими Медиа, что такое Хабрахабр и почему он взлетел — в отличие от прочих ТМ проектов, половину из которых уже закопали, а другая половина летит низенько-низенько.

Дело в том, что Хабр в том его виде, в котором он существовал в 2010 году, был вовсе не «сайтом про IT» типа 3dnews и Ferra. Хабр был, в первую очередь, кружком по интересам. Собралась кучка гиков и обсуждала, в общем, то, что им самим интересно — включая, но не ограничиваясь, космос, настолки, вещества, теорию эволюции, жадность копирастов, гребёнку Чурова и прочая. Периодически ТМ устраивала набеги и банила особо жестокий флейм, но, в целом, ситуация всех устраивала.

Предлагаю вашему вниманию перевод статьи "I’m a web developer and I’ve been stuck with the simplest app for the last 10 days".

От переводчика: мнение автора местами частично, или полностью, не совпадает с моим, но вопрос поднимается, как мне кажется, правильный. Рекомендую почитать комментарии в блоге автора.

В основном я занимаюсь full-stack web-разработкой. Периодически пишу бэкенд на Python или Ruby, иногда работаю с C#. Еще я пишу консольные утилиты на C++ и Node.js. Мне нравится Closure, я познакомился с web много лет назад, когда писал на Perl и PHP, а первые годы профессиональной разработки посвятил программированию на Java.

Когда я впервые встретился с Javascript, он в основном использовался для того, чтобы добавить на страничку "Текущее время". Это были девяностые, когда все хотели приправить свои странички так, чтобы пользователи могли оценить, как это клево: текущий день недели выводится динамически. А спустя какое-то время оказывалось, что Javascript может гораздо больше, и мы получаем полностью динамический HTML — DHTML!

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

Десять дней назад я решил сделать небольшое SPA для себя — маленькая утилита, потенциальный pet-project. Работы дня на два-три. А последние полгода я работал над десктопным проектом на C#. Это была довольно скучная программулина для управления рабочими процессами: webservice-бэкенд и winforms на фронте.

Несколько дней назад я переключил свой сервер с порядка 30-ти сайтами на PHP 7. Некоторые из них были достаточно старыми и составляли широкий набор с различных фреймворков и CMS. Вот несколько советов для тех кто еще не решил переходить на PHP 7 или нет.

Начнем с того что я понимаю что есть много людей которые не считают стабильную версию действительно «стабильной» пока она чуть-чуть не повзрослела, ожидая что еще найдутся какие-то баги или несовместимости. С того что я пока видел, пробуя каждый release candidate как только он выходил, совсем безопасно переключиться на PHP 7 как только он выйдет. Я ни разу не заметил какого-то непонятного поведения или вылета которому виной не был бы я сам. Несмотря на то что это новая версия она не несет много несовместимых изменений, то есть по большому счету можете относиться к ней как к просто PHP 5.7 только существенно быстрее.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Курсы этичного хакинга и тестирования на проникновение.

Если вы увлекаетесь информационной безопасностью и хотите усовершенствовать свои навыки в короткое время — предлагаем ознакомиться с обновленными программами обучения в области практической ИБ от Pentestit.

Разрабатывая уникальные по своему формату и методике обучения курсы этичного хакинга: «Zero Security: A» (начальная подготовка) и «Корпоративные лаборатории» (профессиональная подготовка), мы стараемся сделать обучение не только эффективными, но и удобными. Основное отличие программ обучения заключается в том, что первая рассчитана на базовую подготовку в области этичного хакинга, а вторая — на профессиональную подготовку не только этичного хакинга, но и построения эффективных систем ИБ. В любом случае, даже опытные специалисты, посетившие первую программу, открывают для себя что-то новое, не говоря уже о «Корпоративных лабораториях», включающих материал, по уровню сравнимый с докладами на профессиональных хакерских конференциях. Кроме этого, каждый набор пополняется новым материалом, что позволяет передать специалистам, проходящим обучения, наиболее актуальную на момент обучения информацию.

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

Как и многие сейчас, мы решили попробовать внедрить agile для развития одного из наших решений. Точнее, поскольку в мире разработки ПО нет «черного» и «белого», мы решили «не внедрить agile», а перейти от использования менее гибких подходов к использованию более гибких.

В данном топике я хотел бы описать проблемы, с которыми мы столкнулись, а также привести соображения, как некоторых из этих проблем можно было бы избежать. Написание топика продиктовано желанием способствовать переводу дискуссии про agile из плоскости «как наконец заставить этих старомодных менеджеров перейти к прогрессивным методологиям» в плоскость «как работать по agile наиболее эффективно».

Уже давно у нас в головах была идея создания вебинаров по Agile.
Мой коллега, Сергей Андржеевский, опытный и известный скрам-мастер, который участвует в различных конференциях и круглых столах, где делится опытом работы в Agile-проектах — много «вкусного» и интересного рассказывает своим слушателям. Именно он попросил меня опубликовать эту статью на Хабре (своего аккаунта у него пока нет здесь), т.к. мы смогли запустить нашу серию вебинаров (первый уже состоялся 27 мая — Использование Offshore Agile в Exigen Services, а 21 июня была вторая часть — Важные моменты при переходе на Agile, 19 июля будет третья — Введение в практики Экстремального Программирования (eXP).

Использование Agile методологий (SCRUM, XP и т.п.) становится все более популярным в ИТ-индустрии. Почему это происходит? И как это работает?

На сегодняшний день гибкие методологии лучше всего адаптированы к постоянно ускоряющемуся развитию технологий, появлению новых средств разработки и все более переменчивым требованиям заказчика. Гибкость приобретает сейчас особое значение в силу общих тенденций развития информационных систем — глобальные массовые интернет-сервисы, Web 2.0 с его концепцией «постоянной бета-версии», переориентация с программных продуктов на информационные сервисы (которые по определению гибче и динамичнее), популярность SOA архитектур и т.д.

Один человек в интернете спросил меня, что я могу сказать в пользу методологий Agile.

Agile что? Не существует такой вещи, как методологии Agile.

Всё очень просто. Во-первых, парни из Agile манифеста не владели словом «Agile». Во-вторых, они не говорили сделайте то-то, сделайте это, они просто говорили о том, что мы фокусируемся не на тех вещах.

Если мы (веб-студия или частный разработчик) делаем веб-проект для себя, мы сами вольны выбирать метод разработки: гибкий (Agile) или каскадный («водопад»). Как правило, чем сложнее проект, тем меньше шансов у водопада. Но когда мы делаем сайт для заказчика, метод всегда один: каскадный. Эта статья о том, как (и зачем) убедить заказчика попробовать гибкую модель для сложных веб-проектов.

Множество достаточно опытных разработчиков и менеджеров пробовало Agile, и им не понравилось. Многие директора, руководители и специалисты даже не пробовали, ибо считают Agile религией, которая помогает, если в неё верить, либо, вообще, только создают впечатление эффективности у «верующих».



Понять последних можно, ведь большинство статей и agile-евангелистов говорят, примерно следующее: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

Я ни разу не видел сравнения методов подхода к созданию сайтов. Прекрасно понимаю, насколько это будет субъективно: каждый хвалит то, что умеет делать. И всё же, я решил обобщить свой опыт и наблюдения за тем, как это делают другие. В нашей сфере существует, грубо говоря, три наиболее популярных метода: проектирование, написание «ТЗ» и Agile. Вот их-то я и сравню.

На всякий случай договоримся о терминах:

• Проектирование — это детальная проработка с исследованием: задачи, концепция, коммуникация, архитектура, оценка ресурсов. Об этом я писал ранее неоднократно (можно посмотреть в списке моих постов) и буду продолжать писать.
• Бриф (иногда его называют ТЗ, что неправильно по сути)— требования, общая структура сайта на уровне разделов верхнего уровня и их краткого описания. Об этом писали хабра-авторы в разных статьях: Техническое задание на сайт, Техническое задание: как уберечь себя от ошибок и рисков или Типовой шаблон технического задания на разработку сайта
• Agile — определили общую идею, общие требования, провели в меру желания и способностей проектирование — сценарии, пользователи, архитектура — и понеслась. Никто не знает, когда сайт можно будет запускать; это решается по ходу.

NB. Прошу обратить внимание, уважаемые agile-адепты! Я сознательно использую термин Agile не так, как об этом написано в Википедии или в Манифесте. Я использую его для обозначения подхода, когда команда разработчиков не знает, что получится в итоге и действует короткими пробежками с оценкой промежуточных результатов. Именно это я имел «удовольствие» несколько раз наблюдать как подход к созданию сайта.

Методология сравнения проста как пареная репа: рассматриваем каждый метод с точки зрения его плюсов и минусов, применимости. Всё субъективно, основано на личном опыте и опыте коллег. Рассматривать я буду каждый подход применительно к двум самым распространённым типам сайтов — корпоративный сайт компании и коммерческий стартап-сервис.

Буду очень признателен, если кто-то будет со мной спорить, поделиться собственными мыслями. Ради этого и пишу, собственно. Если кому-то покажется, что я за проектирование — вам не показалось.

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

Сейчас я расскажу про применение техники TDD для разработки моделей, используя Yii-framework.
Изначально предполагается, что была прочитана тема «Тестирование» из официального мануала (http://yiiframework.ru/doc/guide/ru/test.overview).

Итак, окружение настроено и сейчас нашей задачей будет — создать модели категории и продуктов(Category, Product) и покрыть их тестами.

Привет, %username%! Несколько лет назад я познакомился с замечательным фреймворком Yii и с тех пор как только у меня появляется возможность вести проект на нем — я дерусь берусь за нее.

Одной из крутых фич которую я очень люблю, это инструмент Gii, который начиная с версии 1.1.2 входит в состав фреймворка. Сейчас я хочу поговорить сторонних модулях основанных на нем.

Gii «Из коробки» генерирует достаточно функциональный код, часто когда нужно создать мелкую фичу приходится очень мало менять. Но что если нам нужно больше возможностей? К примеру добавить поддержку нескольких языков, или изменит стиль генерируемого кода?
Есть 2 способа расширения: Изменять существующие шаблоны и создавать свои генераторы (ну или использовать уже готовые соответственно). На базе этих возможностей были созданы достаточно интересные продукты для комфортной работы с авто генерацией кода.

Все началось с новой работы, на которой пришлось отказать от Zend и перейти на Yii. При создании личного кабинета для сайта потребовались динамическое добавление полей в форме. После ковыряния в интернете пришло такое решение. Поехали:

Всем привет. Сейчас занимаюсь написанием очередного проекта на Yii и хотел бы поделиться кое-какими наработками. В этой статье я хотел бы описать, каким образом можно расширять функциональность фреймворка с помощью наследования классов CHtml, CActiveForm. Тут нет ничего сложного и инновационного, я просто хотел бы поделиться этим. Моя задача состояла в том, чтобы создать 2 элемента:

• Текст, который при нажатии превращается в input
• Блок, имеющий определенную ширину, в который может не поместиться весь необходимый текст, но при наведении появляется подсказка

Вот пример результата работы следующего кода (код после хабраката):

При написании одного проекта, возникла необходимость в организации мультиязычности на сайте. Причем количество языков не должно ограничиваться двумя и URL должны быть человеко-понятные и SEO оптимизированные. Тоесть ссылки на сайте должны быть вида:
http://mysupersite.ru/ru/contacts для русского языка
http://mysupersite.ru/en/contacts для английского языка
Так как опыт у меня не очень большой, я начал вопрошать гугл. Вариантов, как оказалось, достаточно много, однако из всех мне приглянулся один вариант, который я использовал и слегка модифицировал.

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

Забегая вперёд скажу, что в результате должно получиться вот такое поле, выпадающее меню и кнопка справа для выбора нужных данных.