Пользователь
Python-разработчики, как правило, хорошо знают, что такое и для чего нужен GIL, вопросы по нему встречаются на большинстве собеседований, я и сам люблю их задавать. Но в CPython его скоро не будет. Да, core-разработчики CPython взяли курс на его удаление.
Разберём основные концепции того, как это будет произведено, с обзором соответствующего PEP 703.
Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.
Но в большинстве из них всё ограничивается описанием URL ресурса, мотивацией использовать пагинацию, сложными словами про кэширование и SSL. Это, безусловно, необходимо для общего понимания технологий, но практически не помогает, когда ты сидишь перед пустой страницей и надо начать “проектировать контракт”.
Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).
Часто при проектировании мне помогала следующая идея: было бы здорово проектировать контракт так, чтобы при малейшем изменении/добавлении бизнес-правил его не приходилось сильно трансформировать, так как API является стыковочным звеном между разными слоями приложения. По ходу повествования я приведу пару примеров, чтобы проиллюстрировать такие изменения.
В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.
Подробно рассказал про каждое место работы, что делал для увеличения дохода, за что увольняли. Дал советы, как тебе достичь этой цели более коротким путем, не допустив моих ошибок.
Привет, Хабр!
Так уж повелось, что любой уважающий себя работодатель перенимает передовые
методики FAANG — по этой причине практически во всех IT-собесах есть она: секция алгоритмов. Кто-то ей рад, кто-то не очень, но секция есть и уходить пока не планирует. Поэтому нужно закатать рукава и достойно встретить суровую реальность.
Привет, я работаю в сфере уже около 10 лет, преимущественно по специальности чистой продуктовой аналитики. Иногда я оглядываюсь назад и думаю — с текущим пониманием что и как устроено в работе, как бы я выстраивал свой процесс обучения с нуля?
Эта статья — мои мысли на эту тему. В каком порядке и какие материалы впитывать, чтобы потом комфортно себя чувствовать в любой продуктовой компании.
Из челленджей — все материалы должны быть бесплатными, или достаточно дешёвыми, чтобы была возможность бросить учёбу на пол пути (ну не зашло, бывает) и не жалеть о потраченных деньгах на мега-курс от %big_tech_name%.
В этой статье я попробую собрать план обучения профессии, как бы я вкатывался сейчас, что бы изучал раньше, что позже, на что бы потратил больше сил и времени и т.д. У некоторых пунктов будут аналоги, можно выбрать на свой вкус без потерь качества.
По итогам всех усвоенных материалов, это будет уровень знаний примерно middle+, но фактически, грейды зависят больше от опыта (особенно в программировании), чем от объёма знаний.
И последнее — я тут не пытаюсь продать курсы, поэтому обещать что будет весело, интересно и быстро, а потом вас наймут на 300к/наносек я не буду. Будет долго, местами сложно, иногда душно, пару раз вы захотите слиться и бросить эту идею. Но… нет, тут не будет но 🙂
Ладно, пожалуй хватит предисловия, поехали.
Значение слова – это его использование в языкеЛюдвиг Витгенштейн (сурс)
Что это вообще за магия такая? Коллокация – это просто пара или группа слов, которые часто возникают вместе. Такие комбинации звучат естественно для носителей языка, однако, тем, у кого язык не родной, бывает сложно догадаться до этой естественной комбинации.
А что если я скажу, что они улучшают сразу и вашу способность органично говорить, и канонично писать, и что совсем удивительно воспринимать английский от носителей языка на слух? И главный вопрос, который меня мучает – почему я узнал об этой технике изучения языка только полгода назад? (Рассказ об этой подготовке здесь.)
Внимательно посмотрите на пример с картинки. Как только собеседник начал(а) произносить “pitch d…” ваш мозг, зная нужные коллокации, подскажет, что там должно быть “dark”. Даже если вы плохо расслышали эту часть. Это один из механизмов, через который коллокации позволяют лучше воспринимать язык на слух.
Подробнее о том, как их учить и использовать и будет эта статья.
Disclaimer: если у вас филологическое образование, то вам наверное будет смешно, что кто-то открыл для себя коллокации и их использование для изучения иностранного языка в 202N году, а вот если вы, как и я, когда-то читали “randomize” как “рандомизе”, то возможно эта статья будет вам полезной.
Are you suggesting coconuts migrate?MPHG
В IT важно держать руку на пульсе, поэтому в прошлом году, поглядывая краем глаза очередные курсы, я начал присматриваться к целой онлайн-программе и, к своему невероятному удивлению, узнал, что от меня требуют сертификат английского. Тем временем, давным-давно уже все мои бумажки превратились в филькины грамоты, да разложились на плесень и липовый мёд.
«Непорядок», — подумал я. Так и родилась идея сдавать экзамен по английскому, но почему именно CPE? А не, скажем, CAE (Cambridge C1) или там TOEFL (американский общий тест на знание английского), IELTS (версия этого же экзамена, но от Cambridge).
О том, зачем это всё — и что вообще из всего этого вышло — здесь и пойдет речь. Заодно расскажу, как готовился, что помогло, а что — пустая трата денег и времени. Бонусом — пара рекомендаций фильмов, сериалов, художественной литературы и учебных материалов.
ОСТОРОЖНО — ТРАФИК, да‑да, под катом будет много картинок, личного мнения автора и его же несмешного юмора (придется потерпеть) — ответ на вопрос в КПДВ тоже там!
Дал ему подборку книг, он приходит месяца через два, и с порога такой сразу:
— Я с друзьями не могу разговаривать.
— Ну да есть такой, недостаточек.
интервью Жака Фреско
Всем салют!
Хочу рассказать вам историю о том, как я начинал с уровня — «не могу решить даже 1 easy задачу из 10» до уровня — «могу решить каждую вторую medium задачу» и прошел несколько coding сессий в таких компаниях как Meta, Booking, Careem, Avito...
Приветствую тебя, хаброжитель!
В этой статье разберём 100 вопросов, они покрывают львиную долю того, что могут спросить на собеседовании джуниор Go-разработчика с практически любой специализацией. Конечно же, в реальной работе на Go требуются немного другие скиллы, чем умение быстро ответить на любой вопрос. Однако сложилась добрая традиция делать из собеседования викторину с главным призом в виде трудоустройства — к этому нужно быть готовым.
Данная статья написана по материалам лекций психолога в МФТИ. Эти лекции показались мне очень полезными, поэтому я решил поделиться своим конспектом.
При написании многопоточного приложения нужно помнить о возможности состояния гонки при использовании неатомарных операций. Даже простая задача по увеличению целого числа на единицу в конкурентной программе может вызвать ошибки, с трудом поддающиеся воспроизведению. Но при использовании asyncio мы всегда работаем в одном потоке, а значит можно не беспокоиться о гонках, правда? На самом деле не всё так просто...
В какой-то момент времени я превратился в педанта брюзгу. В фильмах малейшие нестыковки и провалы в логике портят мне весь просмотр. В чатах меня бесит it's вместо its. А в статьях про программирование... Всё плохо. За меня всё уже сказал @AlexanderAstafiev, я лишь процитирую:
Простите, я не могу так больше. Я слишком хорошо знаю Python, чтобы молчать при виде такого кода.
Я устал. Я не могу это читать. Простите за токсичную критику, накипело.
Самое забавное, что, по моим ощущениям, везде я вижу одни и те же классы проблем. Я даже запилил сервис, где можно закинуть код и получить код ревью, и, собрав немного статистики, понял, что 50 типов ошибок достаточно, чтобы покрыть большую часть проблем в чужом коде. Но выборка у меня была небольшая, и я подумал: а что, если проверить много кода?
Хабр - не жалобная книга, я знаю. Но тут история про код, с примерами, разбором антипаттернов и всё такое, поэтому я рискну.
Всё началось, когда я узнал про конкурс красоты кода от Сбера. Я как раз хотел поучаствовать в каком-нибудь эпичным конкурсе, а тут как раз он мне и подвернулся, тем более что я - тот человек, которому есть что рассказать про красивый код. Я даже целую статью запилил о том, как писать красивый и понятный код. Так что что я решил, что в данном случае мои шансы на победу - в отличие от остальных конкурсов - всё же больше 0%. Кроме того, я хотел выступить на конференции PiterPy (спойлер: хрен мне), чтобы рассказать там про красивый код и всё такое, поэтому участие в конкурсе и сравнение результатов было бы классным подспорьем.
В данной статье я покажу на практическом примере как устроена многопоточность в Python, расскажу про потоки, примитивы синхронизации и о том зачем они нужны.
Изначально я планировал что это будет простая и короткая заметка, но пока готовил и тестировал код нашел интересный неочевидный момент связанных с внутренностями CPython, так что не спешите закрывать вкладку, даже если вы уверены что вы знаете о потоках в Python всё :)
class MyCounter(object):
def __init__(self):
self.__counter = 0
def incCounter(self):
self.__counter += 1
def getCounter(self):
return self.__counter
class MyCounter(SyncObj):
def __init__(self):
super(MyCounter, self).__init__('serverA:4321', ['serverB:4321', 'serverC:4321'])
self.__counter = 0
@replicated
def incCounter(self):
self.__counter += 1
def getCounter(self):
return self.__counter