Иногда бывает необходимо развернуть не большое рест апи для своего сайта, сделанного по технологии СПА (Vue, React или др.) без использования каких-либо фреймворков, CMS или чего-то подобного, и при этом хочется воспользоваться обычным php хостингом с минимальными усилиями на внедрение и разработку.  При этом там же желательно разместить и сам сайт СПА (в нашем случае на vue).

Использование php позволяет для построения ендпоинтов апи использовать даже статические php файлы, размещаемые просто в папках на хостинге, которые предоставляют результат при непосредственном обращении к ним. И хотя, видимо в своё время, такой подход послужил широкому распространению php мы рассмотрим далее более программистский подход к созданию апи, который очень похож на используемый в библиотеке Node.js Express и поэтому интуитивно понятен, и прост для освоения.

Кто-то говорит, что в компании главный актив и ресурс — люди, кто-то — средства производства, прагматичные ребята всё сводят к деньгам. И только самые умудрённые опытом знают точно: в компании всё решает доверие. Если его нет, не сложатся отношения с людьми, будут неэффективно использованы средства производства, а деньги станут причиной постоянных споров и раздоров. Только давайте прямо с первого абзаца не будем путать доверие, вседозволенность, раздолбайство и слабую волю руководителя. Доверие — это взаимное чувство уважения, осознание возможностей друг друга и отсутствие страха и стыда перед чужими поступками, перед потенциально неосторожными действиями. 

Казалось бы, как просто: ты доверяешь сотрудникам, они — тебе, вы активно работаете над общими целями и задачами, совместно находите самые успешные решения, каждый получает по труду, все довольны, никто не обижен. (Ой, кажется, я переизобрёл социализм, где моя борода?) Но идеальным сущностям не суждено случиться: увы, обжегшийся один раз руководитель теряет доверие даже к преданным сотрудникам и восстановить его сложно. Порой почти невозможно.

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

Как бороться с Android’ом и не позволять ему уничтожать важные фоновые процессы, расскажет Сергей Смирнов, Android-разработчик CleverPumpkin, который так овладел инструментом WorkManager, что смог в фоновом режиме написать эту статью.

Давайте представим ситуацию, когда вам нужно установить на все виртуальные машины (агенты сервера сборки) определенный пакет Python. Но вы не можете изменить образ агента, а загрузка, к примеру из pypi.org или github.com непроверенных пакетов, ограничена. Как тут не вспомнить последние новости про вредоносные изменения в пакете nmp или более свежую информацию про PyPi.

Python использует подход под названием EAFP — Easier to ask for forgiveness, than permission (легче попросить прощения, чем разрешения). Это значит, что проще предположить, что что-то существует (к примеру, словарь в словаре, или в нашем случае модуль в системе) или получить ошибку в противном случае.

Этот подход, развитый в PEP-0302, позволяет делать хук импорта модулей, что в итоге приводит нас к возможности написания следующего кода:

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

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

Если вы плохо знакомы с Tkinter, вот прекрасный курс, рекомендую >>>

Недавнее исследование MentorcliQ показало, что все компании США из списка топ-50 по версии Fortune используют программы менторства. Также наставничество практикуют 84% компаний, входящих в топ-500. Во время экономического спада из-за Covid-19 у компаний с программами обучения стажёров прибыль была выше, чем у тех, кто не применял такой подход. Но наставничество приносит пользу не только компаниям, но и самим менторам. В статье мы расскажем, в чём заключается эта выгода.

Пишем классическую «Змейку», как на КДПВ, в четыре переменные. По словам автора, «Можно написать и с двумя, но зачем осложнять себе жизнь?» К старту курса по разработке на С++ приглашаем под кат.

Не так давно я захотел написать свой шахматный движок. На удивление в Интернете нашлось не так много хороших статей на эту тему. Были статьи с довольно слабыми программами, многие из которых даже умудрялись пропускать некоторые важные правила. А были статьи с хорошими программами (некоторые из них были даже чуть лучше чем получилось у меня в итоге), но там авторы рассказывали лишь основные идеи, пропуская подробности, из-за чего написать что-то свое по таким статьям было проблематично. Поэтому после написания своей программы, я решил написать статью, дабы облегчить жизнь интересующимся в данной теме. Я не претендую на лучшую шахматную программу или на чистейший код, но эта статья будет хорошим и легким началом для тех, кто хочет написать что-то свое.

Не ждите, пока он обустроится

Казалось бы тяжёлая тема, но со временем меняется отношение даже к такому неприятному вопросу. Сегодня расскажу про то как увольнять людей.

Как становятся тимлидами? Типичный путь в этот омут — “эволюционный”. Ты успешно выполнил кучу экспидайт-эпик-мамонтов, принёс в своё разработческое племя благодатный огонь метрик и мониторинга, показал, что тесты — это хорошо... И вот тебя уже назначают тимлидом — просто по принципу, что ты самый сильный среди других разработчиков. А бывает, что ты слишком долго на проекте, и вот, вуаля, предыдущий тимлид сгорел в битве при Монолите, и теперь по наследству мантия обязанностей переходит к тебе. Ну, и, конечно, путь инициативы — где ты сам вызвался на эту должность, из-за того, что очень ответственный, или от скуки, ради денег, или просто по фану.

Меня зовут Константин, недавно в Каруне я стал тимлидом и тут я поделюсь причинами, почему не стоит необдуманно падать в управленческую бездну.

Термин «автоматное программирование» (АП) был введен в широкую практику в 90-х годах прошлого века [1, 2], хотя о применении автоматов в программировании шла речь задолго до этого. R первым упоминаниям уже начала 70-х годов можно отнести метод введения переменной состояния или, по-другому, метод преобразования неструктурированных программ Ашкрофта и Манны [3]. За прошедшее время сформировалось достаточное число его поклонников и не меньшее число критиков. Если говорить об их разногласиях, то в их основе отсутствие формального определения АП и поверхностное восприятие его возможностей. Из-за этого автоматное программирование формируется интуитивно, что и приводит к противоречивым его формам, порой, мало похожим на первоисточник – модель конечного автомата.

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

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

Все то время, что я подбираю стажеров, я имею дело в основном с выходцами из других профессий. Типичный стажер – человек, который окончил ВУЗ по любому другому профилю (медики, учителя, админы, маркетологи, кого только не было), получил опыт работы по специальности и решил, что ему надо что-то другое. Мотивация перемены области деятельности, как я понимаю, обычно деньги и комфорт. Есть поверье, что средний начинающий программист – это человек, который работает из дома три часа в день, а остальное время купается в деньгах как Скрудж МакДак. 

Все эти чудесные люди практически в обязательном порядке проходят некие онлайн курсы и сразу по прохождении размещают резюме на вакансию junior-программист с ценником от 50 000 рублей. 

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

Математику было достаточно просто изучить?

Я услышал множество хороших отзывов о книге  Calculus Made Easy by Silvanus P. Thompson. Начал читать и правда, это была самая простая книжка на английском, которую я читал (советую попробовать почитать в оригинале), причем понял лучше, чем на родном языке.

Но зачем ее читать взрослым людям, знакомым с математикой не понаслышке?

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

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

Особенно поможет людям, которые мечтали стать хардкорными "дата-сатанисами" и прочими гениями современности, но как-то все не складывалось. Для множества тестеров, эйчаров, проект менеджеров, кто нашел себя в айти, но хочет еще развиваться.

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

Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что мы не до конца выяснили у заказчика и стейкхолдеров все требования, оставив множество умолчаний.

В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.

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

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