Опять же, не злорадства ради, до сих пор нельзя sequence'ы по delete удалять, таблицы можно, причем каскадно, а ключи приходится через консоль и drop sequence: https://youtrack.jetbrains.com/issue/DBE-2750
Giphy, приведенный в статье в пример, больше не использует CAPS. По крайней мере не везде. Не придирка, просто наблюдение, из всех — это, наверное, самый плохой и неэкономичный по площади вариант.
Это какая-то софистика. Предположим, есть должность, на которой единственным заданием является рисование этих ваших треугольников. Как начальник будет оценивать работу сотрудника? Если не сказано иначе, то треугольники могут быть произвольными, соответственно, единственное число-оценка — количество этих самых треугольников. Если треугольники нужны, например, только прямоугольные, то опять же — только количество этих самых прямоугольных треугольников играет роль за вычетом бумаги, потраченной зря на "неправильные" треугольники. Если же перед сотрудником стоит задача нарисовать треугольники так, чтобы их можно было потом вырезать и замостить ими какую-либо фигуру, то тут даже числа много, достаточно булевого значения, выполнена ли работа или нет. Если задача сформулирована абстрактно, типа "нарисуй тут треугольники, чтоб красиво было, и Федор Иванович доволен остался", то, понятное дело, не оценить такую работу числом, но ее и выполнить нельзя гарантированно.
Да нет, это понятно. Вопрос в том, что придется каждый коммит меткой снабжать или творить для каждого коммита ветки, а это лишняя работа в случае веток (которые в 95% случаев сливаются без проблем, а в 5 — оказываются причиной головной боли) или сомнительная польза в случае меток. Ну вот, например, dev-бранча, за неделю на нее пополо 2-3 новых фичи и 5-10 фиксов/мелких улучшений, каждый билд деплоится для тестирования. Практически каждый день — новый билд или два. Велика ли польза от меток на всех соответствующих коммитах, если можно вытащить автоматически хэш коммита и подтянуть в ui список изменений из git-лога автоматически?
Спасибо за перевод. Кластерный рендеринг — для меня что-то новое, надо будет попробовать. Жалко, что ничего нет по SVO (Sparse Voxel Octree). Хотя, я догадываюсь, почему — всю информацию, содержащуюся в статье, автор выцепил из вызовов API, а вот как оно устроено внутри — нужно декомпилировать код. Ну и больше всего удивило, что на интерфейс ушло почти 10% вызовов API, они ведь далеко не бесплатные (ну, по крайней мере в OpenGL, не знаю насчет Vulkan), интересно, почему незаоптимизировали. Хотя, наверное, по сравнению с рендерингом сцены — это пренебрежимо мало.
Это действительно так, но приведу пример из жизни, я работал в компании X, которая купила компанию Y, у которой, в свою очередь, была целая куча кастомеров Z1-Zn. Так вот, в соглашении о покупке прописано, что X не имеет доступа к Zi, хотя эти данные технически хостятся на серверах, которые теперь являются имуществом X. И такое бывает. Но, видимо, не в случае Facebook — WhatsApp
А я, когда клавиатуру выбираю, в первую очередь смотрю на форму клавиш. Не могу я жить, если enter маленький, «американский», все время промахиваюсь. Печально, что клавиатур нормального уровня с большим энтером нет, приходится довольствоваться ашановским noname'ом. А еще logitech, например, додумались сделать левый shift коротким и воткнуть между ним и Z палки-слэши, это вообще ни в какие ворота. Тут хоть этого нет.
Не скажу, что знаю bash в совершенстве, но в нем, на мой взгляд, очень и очень много сомнительных моментов. если бы был выбор, писать на баше или павершелле, я бы, пожалуй, выбрал второй.
Скорее всего, одно из двух: либо не догадались о потере производительности на этом моменте, либо не уделили достаточно внимания описанию в спеке. Человеческий фактор, стандарт большой и его пишет много людей.
Я не web-дизайнер и даже не верстальщик, но, бывает, приходится наваять веб-морду к какой-нибудь тулзе. Расскажите, пожалуйста, почему стоит продолжать использовать px, когда есть гораздо более гибкие vmin, em/rem и %? Мне всегда удавалось обойтись ими, но, как я уже сказал, мои странички далеки от совершенства. Тем не менее, на мой взгляд, использование px — это всегда надежда на то, что пиксели клиента примерно такие же как пиксели разработчика. И если на десктопах это чаще оказывается правдой, то с зоопарком мобильных устройств сказать, сколько займет max-width: 1200px; мне кажется невозможным.
Вы все грамотно написали, не холивара ради я лишь хочу варизить одну свою мысль. При сравнении языков программирования все величины относительны. Ничего не удастся привести к единой шкале просто потому что языки различны. Производительность? В какой момент времени, сразу после старта или после прогрева виртуальной машины? В каких условиях, под какой нагрузкой — слишком много условных переменных. Читаемость, понятность, поддерживаемость? Ну это вообще настолько субъективно, насколько возможно. Если бы это было не так, то не существовало столь большого числа языков на сегодняшний день. Кому-то нравится питон, кому-то больше по нраву руби. Кто-то вообще не считает интерпретируемые или выполняющиеся в ВМ языки настоящим языками. Да, возможно, история склонила определенные языки к определенным целям, условно, си — железо, перл — обработка текста, питон — математическое прототипирование и т.д. Но все же, популярность языка обуславливается свойствами, перпендикулярными всем вышеперечисленным. Мне кажется, что для того, чтобы прижиться, язык должен следовать тем же правилам, что и любой другой программный продукт. А для любого программного продукта в первую очередь важен маркетинг. Даже если продукт бесплатный. В первую очередь, важно, кто стоит за языком. Майкрософт, Гугл, Эппл или Гвидо. Здесь играет роль и психология, наверное. Но вообще, я хотел о другом сказать. Есть единственное исключение, позволяющее сравнить языки по-честному. И это — краткость языка. Речь, конечно, не идет об обфускации. Когда я изучил питон после джавы, я был удивлен, насколько короче можно записать то же самое. Почему это важно? Дело, разумеется, не в том, что программист упирается в скорость набора, а в том, что чем меньше связующего кода и лишних абстракций, тем яснее можно увидеть сам алгоритм, тем меньше приходиться тратить внимание на вещи, прямо не связанные с задачей. Да банально уставившись в экран кода, видишь больше, иногда в разы. Взять, например, геттеры-сеттеры явы, больная мозоль для многих и камень преткновения. Факт в том, что даже будучи автогенеренными, они создают огромное количество шума, который нужно учитывать. Или все эти public static final void… зачем они нужны? Короче говоря, для себя я решил, что краткость кода — одна из первостепенных по важности вещей.
В Бёрдмэне десятки склеек, но они действительно хорошо замаскированы. Есть фильм, снятый совсем без склеек, одним дублем. Это фильм 2015 года Виктория. К сожалению, сам фильм, как по мне, средненький.
Опять же, не злорадства ради, до сих пор нельзя sequence'ы по delete удалять, таблицы можно, причем каскадно, а ключи приходится через консоль и drop sequence: https://youtrack.jetbrains.com/issue/DBE-2750
Не злорадства ради, но может ли быть полная поддержка 3.6 без 3.5?
Синтаксический анализатор до сих пор не понимает простую конструкцию
https://youtrack.jetbrains.com/issue/PY-20682
И статья и софтинка эта и тон статьи, словом все здесь навевает воспоминания о Kickidler. Старший брат следит за тобой.
Giphy, приведенный в статье в пример, больше не использует CAPS. По крайней мере не везде. Не придирка, просто наблюдение, из всех — это, наверное, самый плохой и неэкономичный по площади вариант.
Это какая-то софистика. Предположим, есть должность, на которой единственным заданием является рисование этих ваших треугольников. Как начальник будет оценивать работу сотрудника? Если не сказано иначе, то треугольники могут быть произвольными, соответственно, единственное число-оценка — количество этих самых треугольников. Если треугольники нужны, например, только прямоугольные, то опять же — только количество этих самых прямоугольных треугольников играет роль за вычетом бумаги, потраченной зря на "неправильные" треугольники. Если же перед сотрудником стоит задача нарисовать треугольники так, чтобы их можно было потом вырезать и замостить ими какую-либо фигуру, то тут даже числа много, достаточно булевого значения, выполнена ли работа или нет. Если задача сформулирована абстрактно, типа "нарисуй тут треугольники, чтоб красиво было, и Федор Иванович доволен остался", то, понятное дело, не оценить такую работу числом, но ее и выполнить нельзя гарантированно.
Установка значений
помогла?
Да нет, это понятно. Вопрос в том, что придется каждый коммит меткой снабжать или творить для каждого коммита ветки, а это лишняя работа в случае веток (которые в 95% случаев сливаются без проблем, а в 5 — оказываются причиной головной боли) или сомнительная польза в случае меток. Ну вот, например, dev-бранча, за неделю на нее пополо 2-3 новых фичи и 5-10 фиксов/мелких улучшений, каждый билд деплоится для тестирования. Практически каждый день — новый билд или два. Велика ли польза от меток на всех соответствующих коммитах, если можно вытащить автоматически хэш коммита и подтянуть в ui список изменений из git-лога автоматически?
Это все разумно и понятно, но как быть с дев-билдами? Как отличить билд с фиксом от билда без фикса?
А разве это только в android studio имеется? Мне кажется, во всех IDE от jetbrains, включая IntelliJ IDEA есть такие функции.
А ненажимаемая ссылка на презентацию в конце — это такая ирония?
Спасибо за перевод. Кластерный рендеринг — для меня что-то новое, надо будет попробовать. Жалко, что ничего нет по SVO (Sparse Voxel Octree). Хотя, я догадываюсь, почему — всю информацию, содержащуюся в статье, автор выцепил из вызовов API, а вот как оно устроено внутри — нужно декомпилировать код. Ну и больше всего удивило, что на интерфейс ушло почти 10% вызовов API, они ведь далеко не бесплатные (ну, по крайней мере в OpenGL, не знаю насчет Vulkan), интересно, почему незаоптимизировали. Хотя, наверное, по сравнению с рендерингом сцены — это пренебрежимо мало.
Это действительно так, но приведу пример из жизни, я работал в компании X, которая купила компанию Y, у которой, в свою очередь, была целая куча кастомеров Z1-Zn. Так вот, в соглашении о покупке прописано, что X не имеет доступа к Zi, хотя эти данные технически хостятся на серверах, которые теперь являются имуществом X. И такое бывает. Но, видимо, не в случае Facebook — WhatsApp
Оффтоп, но обновляют, как могут: https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299 Да, это веб-версия, завернутая в окошко, завернутое в свою очередь в пакет, но работает сносно. Пока практически нет настроек и видеозвонков, в остальном — полный аналог виндового.
Не скажу, что знаю bash в совершенстве, но в нем, на мой взгляд, очень и очень много сомнительных моментов. если бы был выбор, писать на баше или павершелле, я бы, пожалуй, выбрал второй.
Скорее всего, одно из двух: либо не догадались о потере производительности на этом моменте, либо не уделили достаточно внимания описанию в спеке. Человеческий фактор, стандарт большой и его пишет много людей.
Я не web-дизайнер и даже не верстальщик, но, бывает, приходится наваять веб-морду к какой-нибудь тулзе. Расскажите, пожалуйста, почему стоит продолжать использовать
px, когда есть гораздо более гибкиеvmin,em/remи%? Мне всегда удавалось обойтись ими, но, как я уже сказал, мои странички далеки от совершенства. Тем не менее, на мой взгляд, использованиеpx— это всегда надежда на то, что пиксели клиента примерно такие же как пиксели разработчика. И если на десктопах это чаще оказывается правдой, то с зоопарком мобильных устройств сказать, сколько займетmax-width: 1200px;мне кажется невозможным.