И снова здравствуйте. В преддверии старта курса «JavaScript Developer. Professional» перевели

11 советов для тех, кто использует Chrome в качестве среды разработки.

Итак, по тем или иным причинам вы решили при разработке ориентироваться на Chrome. Вы открываете инструменты разработчика и приступаете к отладке кода.



Иногда вы открываете консоль, чтобы посмотреть вывод своей программы, или вкладку Elements, чтобы проверить CSS-стили элементов DOM.



А действительно ли вы разбираетесь в Chrome DevTools? На самом деле у инструментов разработчика множество мощных функций, которые облегчают жизнь, но о них мало кто знает.
Я расскажу о самых полезных из них.

У моего друга Сереги была шикарная задумка – вместо обычных SATA-шных HDD Seagate емкостью 6 ТБ по 12 тыс. за штуку закупиться USB-шными накопителями по 8 тыс. с теми же HDD внутри. Затем вытащить их из USB-боксов и поставить в NAS, который затем использовать с минимальными нагрузками под бекапы. Разница на круг получалась хорошей – 16 тыс.

Заказ был сделан. На следующий день курьер привез четыре коробки с голографическими стикерами. И с этого момента все пошло не по плану.


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

Аспектно-ориентированное программирование (АОП) — это парадигма программирования являющейся дальнейшим развитием процедурного и объектно-ориентированного программирования (ООП). Идея АОП заключается в выделении так называемой сквозной функциональности. И так все по порядку, здесь я покажу как это сделать в Java — Spring @AspectJ annotation стиле (есть еще schema-based xml стиль, функциональность аналогичная).

Выделении сквозной функциональности

До



и после



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

Join point

В этом материале я хочу описать очень полезную, и часто используемую аннотацию Conditional и интерфейс Condition.

Контекст Spring — это огромный контейнер различных бинов, как самого спринга, так и пользовательских. Всегда хочется иметь гибкие инструменты управления этим зоопарком бинов. Аннотация @Conditional как раз и создана для этого.

Привет, Хабр!

К нашему стыду, во время самоизоляции мы настолько приуныли, что забыли опубликовать новость об очередном релизе под номером 0.4.13, который состоялся еще в апреле 2020 года. Исправляемся.


Скачать образы системы | Пресс–релиз | Список изменений | TL;DR | Тесты и список регрессий

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

Сегодня на предельно простых примерах посмотрим, к чему это может приводить в контексте использования GROUP/DISTINCT и LIMIT вместе с ними.

Вот если вы написали в запросе «сначала соедини эти таблички, а потом выкинь все дубли, должен остаться только один экземпляр по каждому ключу» — именно так и будет работать, даже если соединение вовсе не было нужно.

И иногда везет и это «просто работает», иногда — неприятно сказывается на производительности, а иногда дает абсолютно неожидаемые с точки зрения разработчика эффекты.


Ну, может, не настолько зрелищные, но…

«Сладкая парочка»: JOIN + DISTINCT

SELECT DISTINCT
  X.*
FROM
  X
JOIN
  Y
    ON Y.fk = X.pk
WHERE
  Y.bool_condition;

Как бы понятно, что хотели отобрать такие записи X, для которых в Y есть связанные с выполняющимся условием. Написали запрос через JOIN — получили какие-то значения pk по несколько раз (ровно сколько подходящих записей в Y оказалось). Как убрать? Конечно DISTINCT!

Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».

Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?



Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.

Согласно исследованию Harvard Business Review, 41% женщин, работающих в IT, в итоге покидают эту сферу (по сравнению с 17% мужчин), и я понимаю почему…

Я научилась программировать в 16 лет, а сейчас мне за 30. Я получила степень кандидата математических наук в университете Дьюка. Я все еще помню свою гордость за алгоритм «хода коня», написанный на C++ в старшей школе; потрясающую головоломку — интерпретатор, интерпретирующий сам себя (курс Scheme моего первого семестра в колледже); мое увлечение различными типами разложениями матриц на C в аспирантуре; и мое воодушевление от реляционных баз данных и веб-скраперов на моей первой работе.

Через десять лет после того, как научилась программировать, я все еще любила алгоритмы, но чувствовала себя одинокой и подавленной в IT-культуре. Во время работы в особенно плохо подходившей компании я была настолько несчастлива, что наняла карьерного консультанта, чтобы обсудить альтернативные карьерные пути. Покинуть IT было бы убийственно, но и остаться было непросто.

Liquibase — это система управления миграциями базы данных. Это вторая статья о Liquibase, на этот раз содержащая советы «боевого» использования системы. Для получения базовых сведений подойдет первая статья-перевод «Управление миграциями БД с Liquibase» (ссылка).

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

Вот 10 вещей, которые в определенный момент работы с Liquibase были для меня открытием.

1. Версионность приложения должна быть отражена в структуре папок миграций

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

/db-migrations
    /v-1.0
        /2013-03-02--01-initial-schema-import.xml
        /2013-03-02--02-core-data.xml
        /2013-03-04--01-notifications.xml
        /changelog-v.1.0-cumulative.xml
    /v-2.0
        ...
        /changelog-v.2.0-cumulative.xml
    /changelog.xml

Подробнее:

Привет, Хабр! Сегодня мы построим систему, которая будет при помощи Spark Streaming обрабатывать потоки сообщений Apache Kafka и записывать результат обработки в облачную базу данных AWS RDS.

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

Как реализовать этот кейс без применения магии и волшебных заклинаний — читаем под катом! Поехали!


(Источник картинки)

Друзья, привет. В статье я расскажу как собрать решение для быстрого старта вашей разработки из standalone Java приложения, брокера и Zookeeper’а Kafka, поднятых в отдельных Docker контейнерах и настроенной plaintext авторизацией для доступа как с локальной машины, так и из внешнего контура.

Готовый проект на github можно забрать в конце статьи

Я уволился из Яндекс.Маркета, отработав там почти 15 месяцев. Сегодня я хочу поделиться своим взглядом на работу в Яндекс.Маркете и рассказать о причинах ухода.

Disclaimer: эта статья бесполезна для тех, кто работает или работал в Маркете; она предназначена в первую очередь для тех, кто лишь планирует туда пойти. А ещё Яндекс.Маркет – это не Яндекс, но очень близко. Поэтому всё, о чём я буду говорить, в первую очередь относится к Маркету, но значительная часть из этого точно так же может быть применена к большому Яндексу.

Я ни в коем случае не претендую на объективность, это моё личное мнение.

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

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

В последние годы JavaScript развивается очень быстро. Особенно это характерно для периода, следующего за выходом стандарта ES6 в 2015 году. С тех пор в языке появилось множество замечательных возможностей. Немало нового было предложено и для включения в стандарт ES2020.



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

Вот есть JavaScript — прекрасная вещь. И прекрасная она на мой взгляд по большей части потому, что дебаггер и отладочные инструменты встроены в каждый Браузер. Без дебаггера и инспектора DOM-дерева было гораздо тяжелее что-либо разрабатывать на JavaScript.

Вот я и решил запилить свой Lisp, но с хорошим дебаггером. Взял маленький, простенький littlelisp и отрефакторил его на 99%. Заточил под пошаговое выполнение и создал свою IDE, простую но работающую.

В итоге получилось следующее.

Иногда в приложениях полезно иметь консоль для управления приложением непосредственно с сервера. Одним из чрезвычайно удобных решений данной задачи является Spring Shell.

Тесты — тоже весьма неплохая практика (надеюсь у вас они есть) и, иногда, они пишутся с аннотацией @SpringBootTest. Однако, если вы подключите Spring Shell и попробуете запустить такой тест, то… ваш тест просто зависнет в ожидании введения команды с консоли.

Итак, отправляемся на поиски решения.

Как сообщает компания Oracle, релиз Java 14 назначен на 17 марта. Интересно, связана ли дата релиза с Днем Святого Патрика (который отмечается как раз в этот день) или нет узнаем совсем скоро. Давайте посмотри на нововведения, которые будут доступны в новой джаве и решим, будем ли мы пить пиво от радости или от горя.

О чем эта статья?

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

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

Статья будет полезна тем, кто хочет сделать свой первый смарт-контракт в TON, но не знает с чего начать.

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

Мы продолжаем рассказ о том, как внутри Одноклассников с помощью GraalVM нам удалось подружить Java и JavaScript и начать миграцию в огромной системе с большим количеством legacy-кода.

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

Если вы не читали первую часть, то очень рекомендую это сделать. Из неё вы узнаете об истории фронтенда в Одноклассниках и познакомитесь с его историческими особенностями, пройдете путь поиска решения проблем, которые накопились у нас за 13 лет существования проекта, а в самом конце окунетесь в технические особенности серверной реализации принятого нами решения.

Сегодня я хочу рассказать о замечательном инструменте, название которого вынесено в заголовок статьи. Разумеется, моей целью не является написание подробного руководства по Apache JMeter. В своей статье я хочу лишь зафиксировать ряд, на мой взгляд, не очевидных моментов, с которыми мне пришлось столкнуться в своей повседневной работе. Я надеюсь, что моя статья будет полезна (сразу предупреждаю, картинок будет много). 

Начинаем новую неделю с очередной интерпретации официальной документации Flutter в формате «вопрос-ответ». 4-я часть освещает в сравнительном стиле Flutter для веб-разработчиков. Она целиком посвящена вёрстке и вышла не такой объёмной, как предыдущие. Традиционно рекомендую всем интересующимся Flutter веб-разработчикам заглянуть под кат, чтобы понять, стоит ли пробовать этот фреймворк и сколько усилий это займёт.