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

Двадцать лет назад

Решил я тут пофрилансить для души, и увидел, что каждый третий проект по разработке чат-бота предполагает интеграцию веб-админки. В основном это касается онлайн-магазинов, где заказчик пытается сэкономить на сайте и заменить его монстрючим чат-ботом. При этом рулить проектом ему удобнее в привычной среде. Отсюда и возникает пунктик — "хочу админку". Функциональность этой штуковины обычно заканчивается на обновлении информации о товарах, назначении админов, управлении рассылками... в общем, простые манипуляции с базой, не более. Так вот, дефолтный разработчик, видя этот пункт, берет, мать ее, Django. Почему? Ну конечно, причина кроется в лени колхозить свою админку, и притащить красивую Джанговую реализацию кажется хорошей идеей. Заказчик, в свою очередь, гуглит топ веб-фреймворков и одобрительно кивает на сей перфоманс. А иногда и подливает масла в огонь, прямо в описании работы пингуя Django.

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

Представим сферическую ситуацию в вакууме. Вы никогда до этого не были предпринимателем, только работали по найму. У вас на руках два оффера. Оба по 100 000 руб. на руки, оба на плюс-минус одинаковых условиях. Офис, 5 дней в неделю по 8 часов. Но один работодатель хочет заключить с вами трудовой договор, а другой предлагает вам оформиться как ИП.

Для начала зададимся вопросом, почему работодатель предлагает оформить отношения с вами как с ИП, а не берёт в штат? Если кратко, то работодателю так проще и дешевле. Почему? Давайте разберёмся.

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

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

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

В 2008 году я устроился ведущим инженером в НИИ Физических измерений, г. Пенза.

Для меня работа в этом НИИ была более чем знакома, я там работал с середины 80-х по середину 90-х. НИИФИ с момента своего создания было сосредоточено на создании датчиков и специализированной измерительной аппаратуры для космической отрасли.

Начало 2000-х характеризовалось тем, что цены на нефть поползли вверх, в государстве появились какие-то деньги, но одновременно стала происходить череда ярких и красочных неудач с нашими ракетами. И вопрос – а что же там происходит с нашими ракетами – создал на НИИФИ фокус ощутимого финансового потока.

Поскольку в этой организации работает куча людей, связанных между собой родственными связями, то, помимо официального молчания по всем щепетильным вопросам, организация была пронизана слухами, что у нас общий бюджет НИИ достиг сначала 0,7 (примерно 2008–2009), далее 0,9; потом 1,3; 2,1 и 2,7 (2012) миллиарда рублей.

Здесь можно задаться очень простым вопросом – а вот кто будет делать интеллектуальное наполнение проектов под эти в общем-то огромные финансовые потоки.

Многие знают эпопею с продлением авторских прав в США — так называемый «Закон о защите Микки Мауса». Такое продление принято связывать с интересами крупных правообладателей, например, студии «Дисней». Однако в XX веке авторские права вообще было принято продлевать — и делали это везде, в том числе в СССР. Что особенно интересно — в СССР и новой России авторское право менялось чаще и серьезнее, чем где бы то ни было: от нулевой защиты то действующих 70+ лет. И, что самое любопытное, у нас неоднократно возвращали произведения из общественного достояния и из государственной собственности, в результате многие работы побывали и под защитой, и в public domain по нескольку раз.

JavaScript сегодня стал одним из наиболее предпочтительных языков для веб-скрейпинга (web scraping). Его способность извлекать данные из SPA (Single Page Application) [одностраничное приложение] повышает его популярность. Разработчики могут с легкостью автоматизировать свои задачи при помощи таких библиотек, как Puppeteer и Cheerio, которые доступны в JavaScript.

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

PostgreSQL и MySQL — это надежные, безопасные и масштабируемые базы данных, которые существуют уже много лет. Каждая из них имеет уникальные сильные и слабые стороны, что делает какую‑либо из них более подходящей для конкретных нужд. В этой статье мы проведем их сравнение, чтобы помочь с принятием обоснованного решения в 2023 году.

Инструкция написана для сервиса github. Вам нужно войти в свой аккаунт или зарегистрироваться.

Все команды вводятся в терминале.

Шаг 1

Делаем fork (копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданный fork.

Selenium WebDriver создавался как кросс-платформенный инструмент для управления веб браузерами. И вот уже почти 14 лет он делает эту работу очень и очень хорошо. Впрочем, автотесты из реального мира создают ситуации, в которых Selenium бессилен. Например, по сценарию нужно загрузить или скачать какой-либо файл. После нажатия кнопки "Загрузить" или "Скачать", поверх окна браузера появляется окно файлового менеджера операционной системы к которому Selenium уже не имеет доступа. Тест останавливается.

Я слышал рекомендации использовать утилиты типа AutoIt или Sikuli для работы с такими системными окнами. Мой совет — никогда так не делайте, это порочная практика, которая приводит к нестабильным тестам:

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

Меня зовут Ярослав Пернеровский. Я уже 15 лет в тестировании и около 8 лет в автоматизации. Сейчас я расскажу как нужно правильно обрабатывать такие ситуации.

Зарплаты и отношение к кадрам в российском ИТ как отображение заката эпохи «среднего класса».

Для лиги лени: «9 из 10 российских работодателей испытывают ужасающий дефицит высококвалифицированных низкооплачиваемых работников, но Юрьев День для оставшихся официально никак не введут, это огорчает эффективных сов».

Эта заметка — приквел к циклу статей «Равновесие Нэша или почему эта музыка будет вечной» и ответ на пост «Вас просто стало слишком много».

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

3. По возможности отправляйте все вопросы в комитеты для «более глубокого изучения и рассмотрения». Стремитесь делать комитеты как можно больше, не менее чем из пяти членов.

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

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

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

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

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

Хабры и Хаброчки, я хотел бы перед самой статьёй обсудить вопрос целесообразности писать свой движок, вместо готовых решений. Есть куча статей, которые опишут разные движки от более популярных до менее. Я бы хотел затронуть немного другой вопрос: "Как человеку, который изучал программирование много лет заняться геймдевом?". Обычно, есть два пути в геймдев:

Умышленный путь. Это когда человек, который играет в игры рано или поздно решит их создать. Тогда, он выбирает где ему учиться этому и выучивает игровые движки и C-образные языки к ним (чаще всего, C#).

Путь прогеров. Программист увлекается математикой и пишет код. Так или иначе, везде где есть код — есть компьютер. Цифровые развлечения (в том числе и игры) не проходят мимо тех людей, который постоянно пишут код. Так, часть прогеров решает написать свою игру и начать свой путь в геймдев. Об этом пути мы и поговорим.

Так зачем выбирать "сложный" путь? Во-первых, не для всех он сложнее. Лично мне сложнее перейти на C# с использованием Unity, чем написать новый проект на Python. Во-вторых, люди не всегда понимают сам движок. Сейчас я преподаю в институте "Бизнеса и Дизайна". Это один из первых профильных учреждений, занимающихся геймдевом. И вот у студентов я спросил зачем им движок. Каково было моё удивление, что далеко не все понимаю, вообще зачем он нужен. Спойлер, не из-за пресетов.

Всех заинтересовавшихся, приглашаю в мир змеиных игр!