В "Многовариантное число различных значений" и "Многовариантные списки частых значений" разделах по два одинаковых плана выполнения. Если я правильно понял, то планы выполнения должны измениться после сбора расширенной статистики. Верно или я чего-то не понимаю?
Предположим веб они поднимут. А с мобильными приложениями что будут делать интересно? Я так понимаю от них была значительная доля трафика (если не основная).
Я правильно понимаю что в Parler помимо обмена сообщениями и постинга картинок был ещё и стриминг видео от пользователей и судя по всему именно для его работы и нужна была большая часть ресурсов?
Внутри IPA файла можно найти такой список бандлов с локализациями. Похоже Uber приложение состоит из кучи разных модулей (разные способы оплаты, всякие модули для водителей от загрузки документов до верификации по selfi и т.п.) и они вполне могут привести к бинарнику весом в 132М (сейчас он столько весит).
Странно что столкнувшись с описанными в статье проблемами и имея такое модульное приложение они не разделили его на приложения для водителей и пассажиров (причем отдельное приложение для водителей у них есть, но в статье про это не сказано). Ну или как минимум не отключили часть модулей (GenderIdentity-Localizations-Helix.bundle или EatsTutorial-Localizations-Helix.bundle например точно нужны? :) )
FYI: Название компании, имя кандидата, его github аккаунт, youtube канал и т.п. находятся за пару минут.
Ага, практика показывает что самое лучшее решение промолчать и не раздувать скандал еще больше. Мотивация простая:
1) быстрее все успокоятся
2) останется меньше негатива в интернет
3) меньше потеряешь своего времени и времени колег (+ то же самое справедливо и для нервов)
Это долгая история. Побробно рассказывать про выбор фреймворка не хочу т.к. это холиварная тема.
Дело было чуть больше 5 лет назад. Выбирал из Qt, Electron, SWT, Swing и JavaFX. Выбрал JavaFX. Практика показала что сделать приложение на JavaFX можно и оно будет неплохо выглядеть и работать, но проблем с ним как и с другими фреймворками хватает. Например, чтобы было понятно, после Jigsaw в JDK «выпилили» jpackage и на несколько лет сборка инсталяторов под разные ОС стала очень не тривиальной задачей. Или например где-то в это же время сломали ListView т.е. если он раньше мог без проблем работать с 1М элементов и более, то теперь он загибается на нескольких тысячах. Это особенно критично если учесть что виртуального режима у ListView нет (как например было в WinForms или Swing) и это кстати тоже серёзная проблема (вроде как glazedlists может ее решить, но я уже не помню чем закончились эксперементы с ним). Всё это можно поправить/обойти при желании, но вместо работы над продуктом прийдётся решать эти проблемы и тратить кучу времени посути впустую и как я писал выше всё это сильно демотивирует.
Я сейчас время от времени смотрю на крос-платформенные UI фреймворки которые уже имеют какую-то историю или недавно появились, но что-то не один не внушает доверия.
Делитесь своими историями и методами которые помогли именно вам сдвинутся с мертвой точки.
Для меня работали следующие практики:
не бросаться сразу писать код
Лучше неделю/месяц потерпеть и потратить это время на анализ конкурентов, составить примерный план работ, завести задачи, если прийдётся с чем-то новым работать, то сделать несколько прототипов и т.п. А вот потом если всё ещё есть смысл продолжать, то браться за написание MVP/прототипа.
тратить на MVP проект не больше 2-х (максимум 3-х) месяцев (это грязное время т.е. работая после работы, в выходные, сидя в машине и т.п.)
Суть в том что на такой период мотивации обычно хватает, а вот на больший период уже нет. Плюс виден результать работы (+ проблемы, возможности и т.п.) и можно оценить стоит продолжать или нет.
не останавливаться даже на день т.е. что-то да надо для проекта каждый день сделать (здоров — пишешь код, заводишь issue, рисуешь иконки и т.п., заболел и не можешь писать код — заведи issue или добавь хотя бы строчку к существующей)
Начнешь пропускать дни — всё встанет и никогда не будет сделано.
использовать инструменты которые ориентированы на быстрое создание прототипов и с которыми есть опыть работы
Я для веб приложений использовал Rails т.к. ИМХО он идеально подходит для создания прототипов/MVP если есть опыт работы с ним. Он посути как конструктор т.е. из готовых блоков можно буквально за пару дней собрать основные экраны, админку, API, за пол часа «прикрутить» аутентификацию, настроить деплой и т.п. При наличии опыта всё делается очень быстро.
Для десктоп приложений всё намного печальнее т.к. обычно хочется сразу сделать крос-платформенное приложение. Пересмотрел/перепробывал много UI фреймворков на разных языках, но у всех у них есть проблемы т.е. вместо того чтобы работать над проектом начинаешь бороться с ограничениями и проблемами этих фреймворков. Всё это сильно демотивирует. Поэтому тут ничего советовать не буду.
Раз факт закрытия границ влияет на цену, хочется понять что в этих «отечественных» сервоприводах изготовлено в России, а что в Китае. Можете объяснить (опять же сайт на этот вопрос не даёт ответа)?
А затем умножить 2 * 28 и получить 56. И прийти к тому же самому вопросу: насколько разумно сравнивать бенчмарки где используются 64 и 56 ядрами между собой (да еще и тогда когода в одном случае 1 процессор, а во втором 2)?
По мне так это shareware продукт с триальным периодом. Только вот в отличии от класической shareware где триал даётся на время здесь вместо времени ограничителем выступают деньги от продажи разработанного приложения.
Так же когда в названии продукта используется «Community Edition» я подразумеваю что вот это самое «коммюнити» которое образуется вокруг продукта может влиять на его развитие и имеет доступ к коду самого продукта (как например сделано у JetBrains с IntelliJ CE). Прочитав FAQ и погуглив я не нашел репозитороия с исходными кодами Delphi и C++Builder Community Edition.
Получается что по сути Embarcadero анонсировало наличие триала у своих продуктов, а не Community Edition.
У Flink-а есть ряд проблем. Я не пользовался им кажется с версии 1.1 и возможно что-то уже изменилось, но тем не менее:
1. Flink очень нестабильный. Например он может работать неделю обрабатывая тысячи сообщений в секунду, потом неожиданно повиснуть так что приходится перезапускать все ноды. Самое плохое что эта нестабильность только увеличивается при выходе новых минорных версий.
1. Чуствителен к сетевым проблемам. Например если пропала связанность между нодами, то кластер может развалится и потом уже не собраться автоматически. Приходится лезь в логи, разбираться что сломалось, перезагружать ноды и flow.
1. Очень прожорлив до CPU. Переписав flow на пару приложений на Java удалось снизить использование CPU процентов на 50 если не больше. Думаю эта особенность может стать bottleneck-ом при частых пиковых нагрузках, либо потребуется больше серверов.
1. Flink не умеет динамически масштабироваться при изменений кластера. Например если одна нода упала, то он перезапускал flow на оставшихся (если мог конечно), а когда нода восстанавливалась, то она оставалась простаивать. Приходилось отслеживать это и вручную перезапускать flow.
1. При запуске flow Flink не умеет подстраивать его под размер кластера (возможно сейчас уже может т.к. эта фича была в планах). Например если нужно запускать вычисление на всех 4-х нодах кластера, то в flow нужно явно указать это. Появляется/удаляется нода — нужно менять код во flow.
1. Отвратительный API для деплоя flow. Если вы хотите задеплоить новую flow, то вам самим нужно сделать savepoint, самим сделать cancel flow (повезёт если он сработает), залить JAR c новым flow и надеятся что изменения которые в нем сделаны подхватстся из сделанного ранее savepoint-а. Мне пришлось написать ужасный скрипт для Gradle который всё это делал.
1. Для сохранения checkpoint-ов и savepoint-ов (если вы подняли кластер Apache Flink) используется HDFS протокол. Заставить работать его требует титанических усилий т.к. части адаптеров (например S3) нет в Flink и он берёт их из инсталяции Hadoop которая должна быть где-то рядом и совместима с Flink. S3 адаптер который используется в этом Hadoop старый и содержит ошибки которые при возникновении выносят весь кластер Apache Flink. Настроить его тоже не просто. Ещё сложнее сделать это если вы живете не в AWS т.к. S3 интерфейс есть только у Riak CS или Minio (с которым адаптер из Hadoop не совместим из-за некоторых особенностей реализации Minio). Всё это выглядит как полный пи**ец т.к. по факту вам всего лишь нужно положить файлик куда-то и скачать его. Я бы сделал это сам, но Flink не дает сделать это в обход HDFS.
1. Очень похоже что есть мемори лики при сохранений checkpoint т.к. его размер стабильно рос и с нескольких сотен килобайт за пару недель он дорастал до сотен мегабайт. Мой flow был не очень большой и я излазил его вдоль и поперёк так что скорее всего ошибка где-то в Apache Flink.
Думаю этого достаточно, хотя это не все проблемы с которыми пришлось столкнуться при использовании Apache Flink.
В целом у меня сложилось следующее впечатление от Apache Flink: идея хорошая и правильная, но реализация — говно. Так же возникло ощущение что с каждым новым релизом ситуация ухудщается.
FYI: Если кому-то нужны тесты которые вы не нашли на сервисе, то пишите здесь или на главной странице сайта. Постараюсь включить их по мере возможности.
В конце прошлого года я решил обновить свой профайл на oDesk и столкнулся с проблемой прохождения тестов. Как было замечено в статье, влоб пройти тесты не так-то просто, так как большинстов вопросов либо устарело, либо относится к таким «закоулкам» технологий с которыми не сталкиваешся в повседневной работе или сталкиваешся очень редко. Как следствие рейт после прохождения тестов оказывается низким (если вообще тест удаётся пройти). Поэтому я собрался с силами и запилил небольшой сервис с тестами и вопросами которые можно встретить на oDesk. Идея сервиса заключается в том чтобы можно просмотреть вопросы и выбрать свои собственные ответы на них перед тем как проходить реальные тесты. Может кому-то этот сервис окажется полезным: odesk-tests.com
И ещё по тестам. Тут в комментариях упомянули про oSTEP. На самом деле тестов на этой платформе у oDesk уже доволно много. Но проблемы которые упомянались она не решает. Это просто обнавлённый UI для прохождения тестов.
А вот тест по PHP сделан очень прикольно. Там пока 3 вопроса и в каждом из них нужно написать небольшую функцию на PHP которую можно прямо в браузере же и отладить. На мой взгляд это более правильный подход проверки знаний чем тесты (хотя и его можно очень просто обойти при желании).
У Elance кстати тоже есть аналог oSTEP только сделан он более продуманно. Во первых, в начале спрашивают контрольный вопрос. Ответив на который можно перейти к остальным вопросам. Это ИМХО позволяет примерно оценить уровень теста ещё не начав его. И во вторых: после ответа на вопрос показывается правильно ты ответил или нет. То есть в отличии от oDesk можно учесть свои ошибки и исправить их в будущем.
===
Кстати раз уж речь зашла о тестах. Есть ли кто-нибудь с freelancer.com Насколько я знаю там тесты сделаны платными. Есть ли какой-то профит от этого решения? И каково качество самих этих тестов?
Спасибо за статью. С тестами на oDesk-е действительно беда. Много вопросов в них устарело и ответить на некоторые не зная версию какойго либо фреймворка или языка программирования просто нереально. А часть вопросов ИМХО вообще содержат неверные ответы.
Есть сервис oDesk Tests на котором собрана большая часть тестов с вопросами которые могут встретиться. Можно перед прохождением реального теста прорешать вопросы на этом сервисе. Это увеличивает шанс пройти тест с первого раза. Так как следующая попытка будет только спустя месяц :(
В "Многовариантное число различных значений" и "Многовариантные списки частых значений" разделах по два одинаковых плана выполнения. Если я правильно понял, то планы выполнения должны измениться после сбора расширенной статистики. Верно или я чего-то не понимаю?
Странно что столкнувшись с описанными в статье проблемами и имея такое модульное приложение они не разделили его на приложения для водителей и пассажиров (причем отдельное приложение для водителей у них есть, но в статье про это не сказано). Ну или как минимум не отключили часть модулей (GenderIdentity-Localizations-Helix.bundle или EatsTutorial-Localizations-Helix.bundle например точно нужны? :) )
Ага, практика показывает что самое лучшее решение промолчать и не раздувать скандал еще больше. Мотивация простая:
1) быстрее все успокоятся
2) останется меньше негатива в интернет
3) меньше потеряешь своего времени и времени колег (+ то же самое справедливо и для нервов)
Дело было чуть больше 5 лет назад. Выбирал из Qt, Electron, SWT, Swing и JavaFX. Выбрал JavaFX. Практика показала что сделать приложение на JavaFX можно и оно будет неплохо выглядеть и работать, но проблем с ним как и с другими фреймворками хватает. Например, чтобы было понятно, после Jigsaw в JDK «выпилили» jpackage и на несколько лет сборка инсталяторов под разные ОС стала очень не тривиальной задачей. Или например где-то в это же время сломали ListView т.е. если он раньше мог без проблем работать с 1М элементов и более, то теперь он загибается на нескольких тысячах. Это особенно критично если учесть что виртуального режима у ListView нет (как например было в WinForms или Swing) и это кстати тоже серёзная проблема (вроде как glazedlists может ее решить, но я уже не помню чем закончились эксперементы с ним). Всё это можно поправить/обойти при желании, но вместо работы над продуктом прийдётся решать эти проблемы и тратить кучу времени посути впустую и как я писал выше всё это сильно демотивирует.
Я сейчас время от времени смотрю на крос-платформенные UI фреймворки которые уже имеют какую-то историю или недавно появились, но что-то не один не внушает доверия.
Для меня работали следующие практики:
Лучше неделю/месяц потерпеть и потратить это время на анализ конкурентов, составить примерный план работ, завести задачи, если прийдётся с чем-то новым работать, то сделать несколько прототипов и т.п. А вот потом если всё ещё есть смысл продолжать, то браться за написание MVP/прототипа.
Суть в том что на такой период мотивации обычно хватает, а вот на больший период уже нет. Плюс виден результать работы (+ проблемы, возможности и т.п.) и можно оценить стоит продолжать или нет.
Начнешь пропускать дни — всё встанет и никогда не будет сделано.
Я для веб приложений использовал Rails т.к. ИМХО он идеально подходит для создания прототипов/MVP если есть опыт работы с ним. Он посути как конструктор т.е. из готовых блоков можно буквально за пару дней собрать основные экраны, админку, API, за пол часа «прикрутить» аутентификацию, настроить деплой и т.п. При наличии опыта всё делается очень быстро.
Для десктоп приложений всё намного печальнее т.к. обычно хочется сразу сделать крос-платформенное приложение. Пересмотрел/перепробывал много UI фреймворков на разных языках, но у всех у них есть проблемы т.е. вместо того чтобы работать над проектом начинаешь бороться с ограничениями и проблемами этих фреймворков. Всё это сильно демотивирует. Поэтому тут ничего советовать не буду.
Как-то так.
По мне так это shareware продукт с триальным периодом. Только вот в отличии от класической shareware где триал даётся на время здесь вместо времени ограничителем выступают деньги от продажи разработанного приложения.
Так же когда в названии продукта используется «Community Edition» я подразумеваю что вот это самое «коммюнити» которое образуется вокруг продукта может влиять на его развитие и имеет доступ к коду самого продукта (как например сделано у JetBrains с IntelliJ CE). Прочитав FAQ и погуглив я не нашел репозитороия с исходными кодами Delphi и C++Builder Community Edition.
Получается что по сути Embarcadero анонсировало наличие триала у своих продуктов, а не Community Edition.
(24-9) — 1.5 (проснулся) — 0.5 (обед) — 1.5 (немного отдохнул) = 11.5
Это всё время проводится за компьютером?
1. Flink очень нестабильный. Например он может работать неделю обрабатывая тысячи сообщений в секунду, потом неожиданно повиснуть так что приходится перезапускать все ноды. Самое плохое что эта нестабильность только увеличивается при выходе новых минорных версий.
1. Чуствителен к сетевым проблемам. Например если пропала связанность между нодами, то кластер может развалится и потом уже не собраться автоматически. Приходится лезь в логи, разбираться что сломалось, перезагружать ноды и flow.
1. Очень прожорлив до CPU. Переписав flow на пару приложений на Java удалось снизить использование CPU процентов на 50 если не больше. Думаю эта особенность может стать bottleneck-ом при частых пиковых нагрузках, либо потребуется больше серверов.
1. Flink не умеет динамически масштабироваться при изменений кластера. Например если одна нода упала, то он перезапускал flow на оставшихся (если мог конечно), а когда нода восстанавливалась, то она оставалась простаивать. Приходилось отслеживать это и вручную перезапускать flow.
1. При запуске flow Flink не умеет подстраивать его под размер кластера (возможно сейчас уже может т.к. эта фича была в планах). Например если нужно запускать вычисление на всех 4-х нодах кластера, то в flow нужно явно указать это. Появляется/удаляется нода — нужно менять код во flow.
1. Отвратительный API для деплоя flow. Если вы хотите задеплоить новую flow, то вам самим нужно сделать savepoint, самим сделать cancel flow (повезёт если он сработает), залить JAR c новым flow и надеятся что изменения которые в нем сделаны подхватстся из сделанного ранее savepoint-а. Мне пришлось написать ужасный скрипт для Gradle который всё это делал.
1. Для сохранения checkpoint-ов и savepoint-ов (если вы подняли кластер Apache Flink) используется HDFS протокол. Заставить работать его требует титанических усилий т.к. части адаптеров (например S3) нет в Flink и он берёт их из инсталяции Hadoop которая должна быть где-то рядом и совместима с Flink. S3 адаптер который используется в этом Hadoop старый и содержит ошибки которые при возникновении выносят весь кластер Apache Flink. Настроить его тоже не просто. Ещё сложнее сделать это если вы живете не в AWS т.к. S3 интерфейс есть только у Riak CS или Minio (с которым адаптер из Hadoop не совместим из-за некоторых особенностей реализации Minio). Всё это выглядит как полный пи**ец т.к. по факту вам всего лишь нужно положить файлик куда-то и скачать его. Я бы сделал это сам, но Flink не дает сделать это в обход HDFS.
1. Очень похоже что есть мемори лики при сохранений checkpoint т.к. его размер стабильно рос и с нескольких сотен килобайт за пару недель он дорастал до сотен мегабайт. Мой flow был не очень большой и я излазил его вдоль и поперёк так что скорее всего ошибка где-то в Apache Flink.
Думаю этого достаточно, хотя это не все проблемы с которыми пришлось столкнуться при использовании Apache Flink.
В целом у меня сложилось следующее впечатление от Apache Flink: идея хорошая и правильная, но реализация — говно. Так же возникло ощущение что с каждым новым релизом ситуация ухудщается.
Что именно выяснилось?
И ещё по тестам. Тут в комментариях упомянули про oSTEP. На самом деле тестов на этой платформе у oDesk уже доволно много. Но проблемы которые упомянались она не решает. Это просто обнавлённый UI для прохождения тестов.
А вот тест по PHP сделан очень прикольно. Там пока 3 вопроса и в каждом из них нужно написать небольшую функцию на PHP которую можно прямо в браузере же и отладить. На мой взгляд это более правильный подход проверки знаний чем тесты (хотя и его можно очень просто обойти при желании).
У Elance кстати тоже есть аналог oSTEP только сделан он более продуманно. Во первых, в начале спрашивают контрольный вопрос. Ответив на который можно перейти к остальным вопросам. Это ИМХО позволяет примерно оценить уровень теста ещё не начав его. И во вторых: после ответа на вопрос показывается правильно ты ответил или нет. То есть в отличии от oDesk можно учесть свои ошибки и исправить их в будущем.
===
Кстати раз уж речь зашла о тестах. Есть ли кто-нибудь с freelancer.com Насколько я знаю там тесты сделаны платными. Есть ли какой-то профит от этого решения? И каково качество самих этих тестов?
Есть сервис oDesk Tests на котором собрана большая часть тестов с вопросами которые могут встретиться. Можно перед прохождением реального теста прорешать вопросы на этом сервисе. Это увеличивает шанс пройти тест с первого раза. Так как следующая попытка будет только спустя месяц :(