Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

Когда вышла версия 1.0 Redux, я решил потратить немного времени на серию рассказов о моем опыте работы с ним. Недавно я должен был выбрать “реализацию Flux” для клиентского приложения и до сих пор с удовольствием работаю с Redux.

Почему Redux?

Redux позиционирует себя как предсказуемый контейнер состояния (state) для JavaScript приложений. Редакс вдохновлен Flux и Elm. Если вы раньше использовали Flux, я советую прочитать, что Redux имеет с ним общего в разделе "Предшественники" новой (отличной!) документации.

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

Доброго времени суток. Так сложилась жизнь что я от недавнего времени стал гордым студентом одного из лучших вузов своей страны. Хорошо или плохо это вопрос спорный, но это не суть. Самое забавное это то, что на лабораторных работах преподаватель то ли для развлечения, то ли для того, что бы в очередной раз напомнить мне что я весьма паскудно разбираюсь в алгоритмике, время от времени выдает задания отличные от того, что получает оставшаяся группа. Одно из последних, которое, как по мне, достойно вашего внимания является сортировка массива без использования условных операторов (if, switch и тому подобных).

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

Для понимания статьи Вам понадобятся минимальные навыки программирования и владение математикой на уровне 9 класса средней школы. Статья рассчитана на людей не знакомых с методами оптимизации или только делающих первые шаги в этом направлении.

_{Фото: A.V. Photography}

Ссылки на предыдущие части и обращение к тем, кто видит публикации Ока впервые:

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

Предыдущие части:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Часть 6
Часть 7
Часть 8
Часть 9
Часть 10
Часть 11
Часть 12
Часть 13
Часть 14

В части №14:
— Давай к сути, — раздраженно сказал Мэтт. — Кто теперь в Гетто главный?

— Ну, это, Босс сейчас главный.

— Босс? Что за Босс? – Спросил Мэтт.

— Ну, это мы так его называем. Ну, а так кличут его Большой Босс, — ответил мужчина. – Мы все так должны его называть. Он теперь заправляет всем в Гетто.

— Понятно, — сказал Мэтт. – Мелли?

— Не врет. И я знаю, куда нам идти.

— Хорошо. С остальным разберешься? – С намеком спросил старый командир.

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



Событие произошедшее на расстоянии 290 миллионов световых лет от Земли, в центре галактики PGC 043234, с трех обсерваторий (Chandra X-ray Observatory, Swift Gamma-ray Burst Explorer, and ESA/NASA’s XMM-Newton) в рентгеновском спектре запечатлено «приливное разрушение» звезды черной дырой, после чего из полученных данных собрали рендер.
Сильнейшая гравитация черной дыры затягивает звезду в себя, нагревая до миллионов градусов и генерируя огромное количество рентгеновского излучения. После всплеска рентгеновского излучения, количество свечение уменьшается, поскольку материал падает за горизонт событий черной дыры, точка, за которой свет не может вырваться, а газовая составляющая по спирали закручивается и падает на ЧД.
На этом примере, ученые первый раз наблюдали как это событие происходит в живую, ну или практически в живую.

К сожалению это всего лишь рендер, но даже и он прекрасен.

Всех с пятницей, уважаемые хабравчане! Как вы знаете, у нас в Почте, Календаре и Облаке используется двухфакторная аутентификация. За месяцы, прошедшие с её внедрения, у службы поддержки накопилось достаточно фактического материала, который ясно даёт понять: многие пользователи (и даже продвинутые) путаются в технических терминах. С чего мы это взяли — под катом.

В статье рассказывается о некоторых этапах ручного изготовления электронных устройств, а особенно подробно о первом этапе: изготовлении печатной платы. Подробные фото процесса помогут разобраться в деталях. А «на десерт», для закрепления теоретического материала, мы соберём простейшее электронное пианино на интегральном таймере NE555.

Привет, Хабр! Эта публикация — попытка развеять некоторые популярные мифы и легенды о MySQL. Я не ошибся с хабом, так как поводом для написания послужила публикация varanio Возможности PostgreSQL, которых нет в MySQL, и наоборот отсюда же. Сама публикация в части критики MySQL хоть и неидеальна, но вполне корректна, а вот комментарии к ней наводят на грустные размышления.

Вообще говоря, я собирался написать публикацию о возможностях MySQL, которые не реализованы или реализованы в PostgreSQL хуже. Но для того, чтобы не мешать много тем в одну публикацию, и учитывая довольно нелёгкую работу по сравнению того, что я знаю очень хорошо (MySQL) с тем, что я знаю очень плохо (PostgreSQL), такую публикацию я решил отложить на потом и для начала ответить сразу на многие комментарии из публикации varanio.

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

_{Фото: A.V. Photography}

Ссылки на предыдущие части и обращение к тем, кто видит публикации Ока впервые:

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

Предыдущие части:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Часть 6
Часть 7
Часть 8
Часть 9
Часть 10
Часть 11
Часть 12
Часть 13

В части №12:

… из ближайших зарослей кустарника, напротив костра, прогремел выстрел, но стрелок промахнулся. Вместо того, чтобы разворотить грудь Оливеру, заряд дроби разнес кору дерева слева от него. Только неточность стрельбы противника и спасла Стальному Генералу жизнь – броню он отключил сразу же после привала, оставив режим «поддержания формы» за неимением с собой брюк. В этом случае боевой костюм был не крепче обычной ткани.

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

В отличие от Оливера, Мэтт не расслаблялся целиком никогда. Сразу же после первого выстрела он схватил карабин, лежавший у него под рукой и, упав на спину, дал по кустарнику длинную очередь; наличие зарослей, которые должны были уберечь их от чужих глаз, сейчас работали на руку атакующим. Слишком сильно они доверились способностям Мелиссы, которые помогали им последние дни избегать редких армейских патрулей.

Наконец-то удалось организовать монтаж и тестирование опытных образцов устройства новой версии. Устройства, выполняющего лишь одну функцию, – уничтожение компьютеров. Впрочем, не будем ограничиваться только компьютерами, устройство способно вывести из строя практически любую технику оборудованную USB Host интерфейсом. К примеру, у меня на столе стоит осциллограф с USB интерфейсом (но он ещё пригодится), практически все смартфоны поддерживают USB OTG режим, TV, роутеры, модемы и т.д.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

БЭМ набирает популярность и становится актуальнее — например, недавно Google выпустил новую библиотеку блоков под названием Material Design Lite, реализованную по БЭМ-методологии. Команда БЭМ тоже не сидела без дела — мы выпустили новую версию библиотеки bem-components, на базе которой построены сайты и проекты не только Яндекса, но и других разработчиков.

Эти события натолкнули нас на мысль ещё раз вспомнить и рассказать вам, как сформировались принципы разработки библиотек в БЭМ-методологии. Надеемся, что многим это будет интересно и полезно. Итак, поехали.



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

Если вы хотите узнать на примерах, как мы пришли к нашим принципам разработки, добро пожаловать под кат.

Мы привыкли видеть истории проектов с миллионами клиентов и целым парком серверов, но разные интересные и курьезные ситуации могут встречаются и на относительно небольших проектах. Одна из них произошла недавно. Однажды работающий нормально сервер вдруг начал случайным образом тормозить…

_{Фото: A.V. Photography}

Ссылки на предыдущие части и обращение к тем, кто видит публикации Ока впервые:

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

Предыдущие части:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Часть 6
Часть 7
Часть 8
Часть 9
Часть 10
Часть 11
Часть 12

В части №10:

— Зачем ты прогнал ее? Ради сестры она готова была остаться. Но эти псевдо-расправы над охраной, пламенные речи человека, мечтающего о геноциде… Зачем?

Деймос сполоснул лицо, плеснул на ладонь лосьона и с силой втер его в идеально выбритый подбородок, после чего ответил:

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

— Я бы сказал, что в таком случае, она поможет всем, — поправил его труп.

— Да, в чем-то ты прав, — согласился Деймос, — пытаясь убить меня, она поможет всем нам.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

Эта статья представляет из себя рассказ о том как устроены исполняемые файлы (в точку! Это именно те штуки, которые получаются после компиляции приложений с расширением .exe). После того, как написан код, подключены библиотеки, подгружены к проекту ресурсы (иконки для окон, какие-либо текстовые файлы, картинки и прочее) всё это компонуется в один единственный исполняемый файл, преимущественно с расширением .exe. Вот именно в этот омут мы и погрузимся.
*Статья находится под эгидой «для начинающих» поэтому будет изобиловать схемами и описанием важных элементов загрузки.

Предлагаю читателям «Хабрахабра» перевод статьи «The land of undocumented react.js: The Context».

Если мы взглянем на React компонент то мы можем увидеть некоторые свойства.

State

Да, каждый React компонент имеет state. Это что-то внутри компонента. Только сам компонент может читать и писать в свой собственный state и как видно из названия — state используется для хранения состояния компонента (Привет, Кэп). Не интересно, давайте дальше.

Props

Или, скажем, properties. Props — это данные, которые оказывают влияние на отображение и поведение компонента. Props могут быть как опциональны так и обязательны и они обеспечиваются через родительский компонент. В идеале, если Вы передаете своему компоненту одинаковые Props — он отрендерит одно и тоже. Не интересно, давайте двигаться дальше.

Context

Встречайте context, причину, по которой я написал этот пост. Context — это недокументированная особенность React и похожа на props, но разница в том, что props передается исключительно от родительского компонента к дочернему и они не распространяются вниз по иерархии, в то время как context просто может быть запрошен в дочернем элементе.

_{Фото: A.V. Photography}

Ссылки на предыдущие части и обращение к тем, кто видит публикации Ока впервые:

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

Предыдущие части:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Часть 6
Часть 7
Часть 8
Часть 9
Часть 10
Часть 11

В части №11:

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

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

— Да, давайте собираться, поговорим в другом месте, — сказал Мэтт, — войска знают, где мы?

— Да, — ответила Мелисса, — у одного из бойцов был с собой маяк и рация.

— Когда плановый выход на связь с центром?

— На рассвете.

— Значит, у нас еще есть часа четыре, — прикинул Мэтт, — собирайте вещи и уходим, объяснишь все это, — он окинул взглядом комнату, остановившись на секунду на теле Джо, — короче, объяснишь все потом. Когда найдем спокойное место.