JIT compilation is a form of dynamic compilation, and allows adaptive optimization such as dynamic recompilation – thus in theory JIT compilation can yield faster execution than static compilation.
В целом, когда руководитель разбирается в технологиях, это хорошо.
Но есть один неприятный момент: бывает, что руководитель думает, что он разбирается в технологиях, но на самом деле это не так.
В таком случае, он берёт на себя принятие некоторых технических решений, вместо того, чтобы делегировать их сотруднику, который более квалифицирован в этой области. Как результат, решение может оказаться не очень хорошим.
pcall, pcall_wraps
Так принято в го, но не в питоне. В питоне принято пользоваться исключениями.
Даже если вам нравится такой стиль, это не повод тащить его в питон: функции у вас в проекте будут вести себя неконсистентно — одни будут кидать исключения, а другие — возвращать ошибку.
Предикаты
Я не понимаю, зачем это нужно, все приведённые примеры записываются одним выражением.
Если хочется иметь функцию, чтобы куда-то ещё её передавать, можно это выражение завернуть в лямбду.
Список и кортеж дополнительно реализуют .reversed, .sorted, .group, .distinct и .apply.
Зачем? Это всё можно делать либо встроенными функциями, либо с помощью list/dict/set comprehensions, либо с помощью generator expressions.
Неужели, у вас вся внутренняя коммуникация в скайпе? Почему бы не взять какой-нибудь слак или хипчат, которые:
1. куда удобнее для этого кейса
2. предоставляют хорошее API для ботов
Слышал версию, что Амазон специально сводит прибыль к нулю, чтобы платить меньше налогов :)
Т. е., когда к концу года прибыль становится положительной, они срочно начинают вкладывать в новые проекты, платить бонусы сотрудникам и т. д., чтобы на бумаге прибыль была нулевой, и чтобы не платить налог на прибыль.
«Час работы по дизайну экономит день работы по кодированию» — это про waterfall.
Реальность такова, что на этапе сбора требований и проектирования учесть все нюансы не получается никак. Даже если на «дизайн» было потрачено очень много времени.
Поэтому, современные методологии работают по другому:
1. Делаем как-нибудь, лишь бы проще, быстрее и работало.
2. Показываем промежуточный результат заказчику, выясняем двигаемся ли мы в нужном направлении.
3. Корректируем направления и повторяем итерацию начиная с пункта 1.
Я думаю, правильнее было бы сначала написать самую простую реализацию, а потому уже — задавать уточняющие вопросы и предлагать улучшения.
Вы так говорите, как будто чуваки из Rails приходят к разработчикам домой, направляют им пистолет в голову, и под угрозой смерти заставляют использовать только Rails и контрибутить только в Rails.
1. Никогда не менять языки/среды разработки/фреймворки на более современные. Начинать новые проекты на Делфи (для США — на Коболе) в 2016 году.
2. Не использовать никаких продуктов по подписке. Пользоваться только купленными продуктами, никогда не обновлять их на более свежую версию.
3. Для всего держать свои собственные физические сервера, но ни в коем случае не нанимать сисадминов. Разработчики должны сами поддерживать свои сервера.
4. Никогда не отдавать на аутсорс ничего. Даже если задача для компании абсолютно не профильная, для неё нужно нанять специального сотрудника в компанию.
> 6. Все рабочие окружения должны быть виртуализированы и перемещены на корпоративный файл-сервер
Не такая плохая идея, ИМХО.
Представьте, что ваше рабочее окружение — виртуалка, поднятая на корпоративном сервере. И вы можете подключиться к ней с любого тонкого клиента в офисе, с корпоративного ноута, и (опционально, если политики безопасности позволяют) с домашнего компьютеры или с личного ноутбука.
Вы получаете доступ к удобному, настроенному окружению в любой момент, откуда угодно. Разве это плохо?
> Один из модераторов WoT сообщил Geektimes на условиях конфиденциальности, что «даже в никах игроков запрещены нацистко-ассоциированные ники, лозунги, аббревеатуры и всё с ними связанное, т.е. чувак с ником zigazaga легко подпадает под пункт о пропаганде и улетает в бан».
Какая конфиденциальность, это же прямо в правилах написано.
Just-in-time compilation
В целом, когда руководитель разбирается в технологиях, это хорошо.
Но есть один неприятный момент: бывает, что руководитель думает, что он разбирается в технологиях, но на самом деле это не так.
В таком случае, он берёт на себя принятие некоторых технических решений, вместо того, чтобы делегировать их сотруднику, который более квалифицирован в этой области. Как результат, решение может оказаться не очень хорошим.
Так принято в го, но не в питоне. В питоне принято пользоваться исключениями.
Даже если вам нравится такой стиль, это не повод тащить его в питон: функции у вас в проекте будут вести себя неконсистентно — одни будут кидать исключения, а другие — возвращать ошибку.
achain, ichain
В питоне 3.6+ будет способ это делать нативно:
None-aware operators — www.python.org/dev/peps/pep-0505
Предикаты
Я не понимаю, зачем это нужно, все приведённые примеры записываются одним выражением.
Если хочется иметь функцию, чтобы куда-то ещё её передавать, можно это выражение завернуть в лямбду.
Список и кортеж дополнительно реализуют .reversed, .sorted, .group, .distinct и .apply.
Зачем? Это всё можно делать либо встроенными функциями, либо с помощью list/dict/set comprehensions, либо с помощью generator expressions.
Средства, насколько я понял, стандартные: скриншоты и активные приложения.
Если честно, я пока не понял, чем оно лучше какого-нибудь Hubstaff
Скайп? Неожиданное решение :)
Неужели, у вас вся внутренняя коммуникация в скайпе? Почему бы не взять какой-нибудь слак или хипчат, которые:
1. куда удобнее для этого кейса
2. предоставляют хорошее API для ботов
Лолчто?
Т. е., когда к концу года прибыль становится положительной, они срочно начинают вкладывать в новые проекты, платить бонусы сотрудникам и т. д., чтобы на бумаге прибыль была нулевой, и чтобы не платить налог на прибыль.
Реальность такова, что на этапе сбора требований и проектирования учесть все нюансы не получается никак. Даже если на «дизайн» было потрачено очень много времени.
Поэтому, современные методологии работают по другому:
1. Делаем как-нибудь, лишь бы проще, быстрее и работало.
2. Показываем промежуточный результат заказчику, выясняем двигаемся ли мы в нужном направлении.
3. Корректируем направления и повторяем итерацию начиная с пункта 1.
Я думаю, правильнее было бы сначала написать самую простую реализацию, а потому уже — задавать уточняющие вопросы и предлагать улучшения.
Если недовольных вроде автора — больше одного, то они вполне могут этим заняться.
Как можно убить open-source проект? Не нравится — форкайся и продолжай пелить так, как нравится.
Российская Федерация — Россия
Республика Беларусь — Белоруссия
2. Не использовать никаких продуктов по подписке. Пользоваться только купленными продуктами, никогда не обновлять их на более свежую версию.
3. Для всего держать свои собственные физические сервера, но ни в коем случае не нанимать сисадминов. Разработчики должны сами поддерживать свои сервера.
4. Никогда не отдавать на аутсорс ничего. Даже если задача для компании абсолютно не профильная, для неё нужно нанять специального сотрудника в компанию.
Не такая плохая идея, ИМХО.
Представьте, что ваше рабочее окружение — виртуалка, поднятая на корпоративном сервере. И вы можете подключиться к ней с любого тонкого клиента в офисе, с корпоративного ноута, и (опционально, если политики безопасности позволяют) с домашнего компьютеры или с личного ноутбука.
Вы получаете доступ к удобному, настроенному окружению в любой момент, откуда угодно. Разве это плохо?
Какая конфиденциальность, это же прямо в правилах написано.