Я в аналогичной ситуации года 4 назад пытался купить Dell S2718D. Но нашёл только последний с витрины и что-то в нем было не так. Не помню уже. А сейчас он уже устарел и в продаже его нет.
Ещё из интересных вариантов монитор DNS, модель не помню, но матрица у него от Cinema Display 27. У родителей у меня до сих пор такой работает, но тоже вряд ли найдёте.
Могут, я одно время работал в Малайзии и у нас работали и иранцы и сирийцы. Видимо потому что Малайзия страна мусульманская и вообще открыта к эмигрантам хоть откуда.
Нормальные парни кстати, без всяких дурацких стереотипных о них представлений
Простите, но вся статья полна менеджер коих ошибок, а обвиняет вы в них неких "универсалов" которых же сами и выдумали.
Всё кейсы происходят по одному сценарию:
берём человека, который занят на другими задачами
запихиваем ему задачу которая ему не интересна, вне его компетенции и т.п.
не контролируем качество, но давим на сроки
профит
Собственно а вы чего ожидали в этом сценарии?
Человек делает на отъебись потому что вы его поставили в такую ситуацию.
Если вы реально хотите эту задачу сделанную хорошо, то как минимум должны разгрузить человека от других задач, как-то замотивировать делать то что он не хочет, оказать помощь/обучение если компетенции недостаточно и самое главное контролировать качество.
Т.е. Кто-то должен проверить что документация написана, тест листы составлены и т.п.
А сейчас вы ведёте себя как "эффектный менеджер", где все заслуги (выполнили в срок) ваши, а косяки они от разработчиков.
Я конечно не знаю какие у вас были предпосылки, может 1 час на отправить в ответ решение. Но как человек с одной стороны решивший много подобных заданий и проходивший (с месяц назад решал подобное про парковку, но посложнее), а с другой как сам периодически собеседующий могу вам сказать, что увидев такое решение даже код читать не будут.
Нужна нормальная структура проекта как минимум, в идеале DDD и unit-тесты.
Итого: обнаружили что код-ревью занимает долго, оказалось неправильно считали и почему-то этим занимаются не все.
Почему вообще все программисты не могут делать ревью, а не только особо провинившиеся?
Могу подвердить, на своем вебсервисе сталкивались с таким. Есть страничка которая доступна только по прямой ссылке и ссылка нигде не появляется кроме как у того пользователя кто изначально на нее попал. Оказалось что на некоторые такие странички попадают и другие пользователи, что в нашем случае не так критично, но все-таки.
Оказалось что ситуация наблюдается только когда User-Agent исходного создателя -Яндекс.Браузер и попадают на нее в основном пользователи Яндекс.Браузера (видимо потому что у них поиск по-умолчанию Яндекс). Так что браузер сливает еще как
Код конечно оставляет желать :). Видно что программируете вы совсем недавно. Впрочем все мы там были, нужно просто развиваться дальше. Рад что вы довели какую-то задачу до конца и помню свои восторги на этой стадии изучения программирования :).
Начнем с начала. В колоде 52 карты, и вы случайно генерируете карту и пытаетесь ее вставить в колоду, если ее там еще нет. Это очень неэффективно. Представьте сколько раз придется генерировать последнюю карту пока попадется правильная. Гораздо правильнее генерировать полностью колоду и потом только ее перемешивать.
Например, сохраняя совместимость с вашим кодом, это могло бы выглядеть примерно так (пишу прямо тут в редакторе, так что могут быть опечатки):
Если то что функция shuffle использует псевдослучайные числа, можно написать свою используя mt_rand, там всего-то строки 4.
Далее, pokerFlush создает 4 массива и использует 4 ветки кода для работы с ними. Было бы гораздо удобнее создать массив из 4 массивов и просто обращаться по индексу масти.
function pokerFlush(array $arrayCards) {
$suits = array_fill(0, 4, []);
foreach ($arrayCards as $card) { //создаю 4 массива, содержащих разные масти исходного массива
$suit = floor($card / 100);
$suites[$suit][] = $card;
}
//и 4 огромных ифа тоже станут не нужны
for($suit = 0; $suit < 4; $suit++) {
if (count($suits[$suit]) >= 5) {
...
return $result;
}
}
return 0;
}
А в чем проблема-то? Так же как вы и вы жизни обрабатываете. Либо БД сама разрулит, либо, если все в памяти — использовать конкурентные структуры данных.
Но на самом деле еще проще, на самом деле одновременных запросов на запись и чтение вроде не намечается. Вся запись в фазе 2
Вобщем-то задача не совсем про highload получилась. В реальном highload нужен большой RPS, и возможность легко масштабироваться, а latency не так критична. А 2000 RPS выдаст вообще что угодно не сильно скриптовое.
Опять же, важно чтобы когда у вас вместо 5000 RPS стало 50000 RPS вы просто добавили серверов. А когда надо добавить фичу — просто ее добавили. А здесь победит C/C++-шный велосипед, с libevent, hashmap и btree в памяти и конечным автоматом вместо полноценного парсера JSON. Как это относится к highload — сложно сказать.
Я даже думал написать такой на Scala (на плюсах 10 лет не писал), но объективно понимаю что код который хочется писать (production-ready) даже близко к топу не окажется.
Может стоило скажем запускать 2-5-10 слабых контейнеров чтобы частью задачи было распределение нагрузки и синхронизация хранилища? Тут уже встал бы вопрос делать одно выделенное хранилище или распределять запросы, скажем по id. И как тогда считать запросы на аггрегацию. Желательно чтобы еще посреди теста рандомные контейнеры дохли и новые поднимались.
И объем данных увеличить чтобы не влезал в оперативную память, а в идеале и на винт одной единственной машины. В принципе тоже понятно как решать такую задачу, но уже скорее использовали бы какие-то СУБД чтобы не изобретать кластеризацию на коленке.
А чем второй путь отличается от первого? Чем вы рендерите во втором способе? Собственно вопрос-то в том как не держать второй комплект шаблонов и т.п. на серверной стороне.
Красиво, но пока старый, кажется, работает быстрее и функциональнее.
Например, как не тыкал, не нашел как в новом посмотреть состояние перевода.
В старом же прям на первой странице в списке операций можно нажать на иконку и увидеть сначала чек, а когда сделают платежку и ее, где виден статус.
В новом же тебе только показывает структуру затрат.
Не пойму каким именно образом follow-письма помогут отфильтровать сеошные отзывы? Информацию о заказе вы же от магазина получаете, я так понимаю? По-моему вы только подставляете себя этим утверждением
Аналогично. Рассылаем только уведомления, без рассылок, хотя уведомления могут угодить группам людей, они не 100% идентичные. Есть всякие автоотписки и FBL настроен и все что хочешь. Все равно письма идут в спам и хорошо если не в режект сразу.
С другой стороны когда сразу идет режект хоть в логах есть ссылка для создания обращения. Они там потупят, руками что-то ковырнут, письма начинают доходить, потом снова все начинает валится в спам.
В последнее время нас хотя бы сразу не режектит, а в спам кладет.
Не очень понятно. Можно в общем-то считать что репликация это выход одного сервера БД и вход другого. Но тогда нужно предусмотреть чтобы не подключали выход БД к чему попало.
Пока очень сыро. Из замеченного сразу:
!!! При удалении связи удаляется также и элемент на вход которого она шла, даже если на нем висит еще много всего. Я так убил типа главный бекенд со всеми связями от него.
— Элемент при перетаскивании из тулбара падает не туда где ты его бросил.
— Процесс перетаскивания не очевиден, что в паре с пунктом выше люто доставляет
— Не сразу понял как рисовать связи, не очевидно
— Нельзя рисовать связь от входа элемента к выходу другого, только наоборот
— В процессе рисования связи временная линия рисует совсем не туда где мой курсор
— Нельзя никак соедининить 2 БД чтобы показать репликацию или кластер (пробовал мускули)
Не любого струйника, а обозначенных выше как экономичные. Они идут от 6 тысяч рублей, мой лазерник стоил около 5, какой-то огромный кенон, сейчас уже не выпускается.
Другу дарили Xerox Phaser 6000, тоже в районе 5. В целом до 6 тыщ есть приличный выбор цветных лазерников. Нужно только смотреть чтобы заправлялись без проблем
Ну все не так плохо, но жаль что проблема так и не решена полностью Не поймите меня неправильно, мне не жалко печатать раз в две недели, но я же просто не вспомню. А прочистка, по опыту когда-то бывшего у меня струйного эпсона, кушает значительное количество чернил. Так что для тех кто печатает редко видимо цветной лазерник таки не заменить.
Я в аналогичной ситуации года 4 назад пытался купить Dell S2718D. Но нашёл только последний с витрины и что-то в нем было не так. Не помню уже. А сейчас он уже устарел и в продаже его нет.
Ещё из интересных вариантов монитор DNS, модель не помню, но матрица у него от Cinema Display 27. У родителей у меня до сих пор такой работает, но тоже вряд ли найдёте.
LG oled телевизоры. Нынче от 42 дюймов. Глянец и картинка лучше всего упомянутого в статье
Ответ "Обращение к итальянцу" тоже, хотя казалось бы
Нормальные парни кстати, без всяких дурацких стереотипных о них представлений
Простите, но вся статья полна менеджер коих ошибок, а обвиняет вы в них неких "универсалов" которых же сами и выдумали.
Всё кейсы происходят по одному сценарию:
Собственно а вы чего ожидали в этом сценарии?
Человек делает на отъебись потому что вы его поставили в такую ситуацию.
Если вы реально хотите эту задачу сделанную хорошо, то как минимум должны разгрузить человека от других задач, как-то замотивировать делать то что он не хочет, оказать помощь/обучение если компетенции недостаточно и самое главное контролировать качество.
Т.е. Кто-то должен проверить что документация написана, тест листы составлены и т.п.
А сейчас вы ведёте себя как "эффектный менеджер", где все заслуги (выполнили в срок) ваши, а косяки они от разработчиков.
Нужна нормальная структура проекта как минимум, в идеале DDD и unit-тесты.
Итого: обнаружили что код-ревью занимает долго, оказалось неправильно считали и почему-то этим занимаются не все.
Почему вообще все программисты не могут делать ревью, а не только особо провинившиеся?
Оказалось что ситуация наблюдается только когда User-Agent исходного создателя -Яндекс.Браузер и попадают на нее в основном пользователи Яндекс.Браузера (видимо потому что у них поиск по-умолчанию Яндекс). Так что браузер сливает еще как
Начнем с начала. В колоде 52 карты, и вы случайно генерируете карту и пытаетесь ее вставить в колоду, если ее там еще нет. Это очень неэффективно. Представьте сколько раз придется генерировать последнюю карту пока попадется правильная. Гораздо правильнее генерировать полностью колоду и потом только ее перемешивать.
Например, сохраняя совместимость с вашим кодом, это могло бы выглядеть примерно так (пишу прямо тут в редакторе, так что могут быть опечатки):
Если то что функция shuffle использует псевдослучайные числа, можно написать свою используя mt_rand, там всего-то строки 4.
Далее, pokerFlush создает 4 массива и использует 4 ветки кода для работы с ними. Было бы гораздо удобнее создать массив из 4 массивов и просто обращаться по индексу масти.
и так далее можно упростить практически весь код.
Но на самом деле еще проще, на самом деле одновременных запросов на запись и чтение вроде не намечается. Вся запись в фазе 2
Опять же, важно чтобы когда у вас вместо 5000 RPS стало 50000 RPS вы просто добавили серверов. А когда надо добавить фичу — просто ее добавили. А здесь победит C/C++-шный велосипед, с libevent, hashmap и btree в памяти и конечным автоматом вместо полноценного парсера JSON. Как это относится к highload — сложно сказать.
Я даже думал написать такой на Scala (на плюсах 10 лет не писал), но объективно понимаю что код который хочется писать (production-ready) даже близко к топу не окажется.
Может стоило скажем запускать 2-5-10 слабых контейнеров чтобы частью задачи было распределение нагрузки и синхронизация хранилища? Тут уже встал бы вопрос делать одно выделенное хранилище или распределять запросы, скажем по id. И как тогда считать запросы на аггрегацию. Желательно чтобы еще посреди теста рандомные контейнеры дохли и новые поднимались.
И объем данных увеличить чтобы не влезал в оперативную память, а в идеале и на винт одной единственной машины. В принципе тоже понятно как решать такую задачу, но уже скорее использовали бы какие-то СУБД чтобы не изобретать кластеризацию на коленке.
Например, как не тыкал, не нашел как в новом посмотреть состояние перевода.
В старом же прям на первой странице в списке операций можно нажать на иконку и увидеть сначала чек, а когда сделают платежку и ее, где виден статус.
В новом же тебе только показывает структуру затрат.
С другой стороны когда сразу идет режект хоть в логах есть ссылка для создания обращения. Они там потупят, руками что-то ковырнут, письма начинают доходить, потом снова все начинает валится в спам.
В последнее время нас хотя бы сразу не режектит, а в спам кладет.
!!! При удалении связи удаляется также и элемент на вход которого она шла, даже если на нем висит еще много всего. Я так убил типа главный бекенд со всеми связями от него.
— Элемент при перетаскивании из тулбара падает не туда где ты его бросил.
— Процесс перетаскивания не очевиден, что в паре с пунктом выше люто доставляет
— Не сразу понял как рисовать связи, не очевидно
— Нельзя рисовать связь от входа элемента к выходу другого, только наоборот
— В процессе рисования связи временная линия рисует совсем не туда где мой курсор
— Нельзя никак соедининить 2 БД чтобы показать репликацию или кластер (пробовал мускули)
Chrome, Debian Linux
Другу дарили Xerox Phaser 6000, тоже в районе 5. В целом до 6 тыщ есть приличный выбор цветных лазерников. Нужно только смотреть чтобы заправлялись без проблем