Вот заходит такой юзер, незнакомый с этой концепцией на страницу и...
где самые свежие сообщения?
где самые популярные сообщения?
я тут был вчера, как мне почитать только то, что я еще не видел?
тут кто-то сделал годный вброс, как почитать все отклики? Причем я хочу иметь возможность как спускаться по дереву откликов, так и вернуться на уровень вверх, если дискуссия ушла в шлак.
Меня даже плиточный интерфейс раздражает неупорядоченностью, хотя я и понимаю головой, что читать надо слева направо сверху вниз, а вот это… боюсь, люди не поймут.
ES не является СУБД. СУБД, помимо операций чтения, записи и поиска данных, должна обеспечивать хранение данных. Т.е. иметь качественый тулинг для:
бэкапа и восстановления данных. Уточню, надежного и работающего бэкапа а не "скопируйте файлы базы"
восстановления базы после программного или аппаратного сбоя. Совсем хорошо, если автоматического восстановления.
просмотра и ручной модификации данных. Например, для "вычистки" грязных данных из базы
ETL/другие формы импорта/экспорта.
Упрощая, должна быть процедура бэкапа, база не должна отказываться стартовать из-за отключения света, смены конфигурации кластера или неправильной фазы луны, база не должна лечиться перезапуском рабочих процессов, должен быть приличный GUI и SDK для разработчика, должны быть средства интеграции.
В большинстве NoSQL решений вышеописанное находится в зачаточном состоянии. Даже в той же монге.
Я думаю, что правильное решение — в связке NoSQL СУБД + ElasticSearch.
Первый хорошо хранит и извлекает данные по ключам, а второй легко находит денормализованные данные по произвольному запросу.
Сумневаюсь я сильно в такой концепции. Построить город — это не много, это ОЧЕНЬ много денег. Которые надо будет "отбивать" всё время существования этого города (сотни лет?). На такие инвест-проекты способно только государство.
Тема и правда очень интересная, достаточно взять и написать самому простенькую реализацию атома на 150 строк. Штука безумно интересная для любого UI, сейчас я пытаюсь её "втянуть" в известную концепцию событий и промисов.
https://jsbin.com/ligibuqayi/1/edit?js,console,output
Открываем консоль, вводим два раза быстро Rest.resource('http://ya.ru')
После второго раза ошибка: "Cyclic atom dependency of Rest.resource(\"http://ya.ru\")"
А как решается проблема с событиями. Не любые переходы интерфейса можно описать атомами.
Как, к примеру, будет выглядеть пример с двумя radio button-s? Т.е. есть две кнопки, каждая обернута в двусторонний биндинг atom<boolean>. Как изобразить условие, что при нажатии на свободную кнопку вторая должна быть отключена?
Мне в качестве первого этапа собеседования в Nest (куплен Google) предложили придумать архитектуру небольшого проекта и снять "professional-looking" видео с рассказом о ней. Отказался.
Если интересно мое мнение, опыта у вас много, но читаете по профессии недостаточно)
При оценке быстродействия структур данных положено различать разные операции над ними и использовать o-нотацию. big data, map-reduce, сортировка в кластере, наверное, знакомы всем, кто активно интересуется современным IT. Самый простой способ решить такую задачу — сортировка слиянием (merge sort). Имхо, каждый уважающий себя программист должен прочитать хотя бы одну книжку по алгоритмам. Мне нравится вот эта: http://www.ozon.ru/context/detail/id/6290126/
Конечно, нельзя требовать знание всего этого с джуна… но кто сказал, что эти вопросы годятся только для него?)
Не статья, а просто какой-то кошмар работодателя. Расскажу со стороны собеседующего: разместили вакансию, и тут поперли косяком люди с красивыми резюме, но в программировании ни в зуб ногой. Почти всем хватило трех простых вопросов:
расскажите об особенностях быстродейтвия ArrayList vs LinkedList
напишите программу, которая читает текстовый файл с диска, сортирует в нем строки и сохраняет в другой файл
видел. мне в нем очень не понравилось, что он позволяет тихо переопределить уже загруженный инстанс класса — т.е. если что-то будет объявлено в разных модулях дважды, я об этом так и не узнаю.
Во-первых, эмуляция оставляет желать лучшего, прежде всего, эмуляция устройств, сети и /proc.
Во-вторых, десятка стала шибко умной ОС, которая решает всё за пользователя. Не то чтобы это было плохо, но текущие реалии — вин10 безобразно много обращается к диску, когда ее не просят. Что делает линукс более производительной ОС.
В-третьих, перенос большого кол-ва драйверов в юзермод, это, конечно, концептуально круто, но заикания музыки и лаги переключения раскладки при сильной загрузке системы удручают. Не говоря уже о том, что, пока я сидел под вин10, я успел подзабыть что такое отзывчивый интерфейс — когда UI реагирует СРАЗУ после клика.
А также
5) много дополнительного кода
6) сложно конфигурировать в рантайме, т.к все зависимости прописаны в коде
7) самое важное — сложно тестировать, т.к. запуск модуля с парой моков вместо реальных классов сделать очень непросто. Также подход с синглтонами усложняет параллельное тестирование
По моему опыту, самый оптимальный DI для больших проектов на скале — это Guice.
Вообще печально наблюдать, как академическое scala-сообщество наступает на уже отполированные Java/C++ программистами грабли. Что синглтоны — это плохо, что перегрузка операторов превращает программу в нечитабельное мессиво...
Ага, но если бы всё было так просто. Тестировать надо а) то, что сломается и б) то, что, сломавшись, нанесет наибольший ущерб. Обычный баланс качество/трудозатраты, и, чтобы его соблюсти, нужно уметь предсказывать будущее. Или иметь очень большой опыт.
Прежде всего компонент должен "работать" — т.е. быть пригодным для использования пользователем, пусть и с багами. Если он падает с ошибкой или не позволяет показать все данные, то на выходе получается принципиально не работающее приложение.
Имхо, при написании тестов на UI нужно почаще задавать себе вопрос "что именно мы хотим проверить". Для этого компонета я бы назвал самым важным тестом "он показывает все элементы, если поле фильтра пустое". Ключевое слово — "показывает".
Вот заходит такой юзер, незнакомый с этой концепцией на страницу и...
Меня даже плиточный интерфейс раздражает неупорядоченностью, хотя я и понимаю головой, что читать надо слева направо сверху вниз, а вот это… боюсь, люди не поймут.
hypers gonna hype.
Оба подхода имеют право на жизнь, но, имхо, лучше писать быстрые бэкенды.
За эволюцией веб-сообщества можно наблюдать бесконечно. Вот примерная история:
ES не является СУБД. СУБД, помимо операций чтения, записи и поиска данных, должна обеспечивать хранение данных. Т.е. иметь качественый тулинг для:
Упрощая, должна быть процедура бэкапа, база не должна отказываться стартовать из-за отключения света, смены конфигурации кластера или неправильной фазы луны, база не должна лечиться перезапуском рабочих процессов, должен быть приличный GUI и SDK для разработчика, должны быть средства интеграции.
В большинстве NoSQL решений вышеописанное находится в зачаточном состоянии. Даже в той же монге.
Я думаю, что правильное решение — в связке NoSQL СУБД + ElasticSearch.
Первый хорошо хранит и извлекает данные по ключам, а второй легко находит денормализованные данные по произвольному запросу.
Сумневаюсь я сильно в такой концепции. Построить город — это не много, это ОЧЕНЬ много денег. Которые надо будет "отбивать" всё время существования этого города (сотни лет?). На такие инвест-проекты способно только государство.
Поселок на 10 тыс человек не в счет.
Тема и правда очень интересная, достаточно взять и написать самому простенькую реализацию атома на 150 строк. Штука безумно интересная для любого UI, сейчас я пытаюсь её "втянуть" в известную концепцию событий и промисов.
https://jsbin.com/ligibuqayi/1/edit?js,console,output
Открываем консоль, вводим два раза быстро
Rest.resource('http://ya.ru')После второго раза ошибка:
"Cyclic atom dependency of Rest.resource(\"http://ya.ru\")"Сыровато.
А как решается проблема с событиями. Не любые переходы интерфейса можно описать атомами.
Как, к примеру, будет выглядеть пример с двумя radio button-s? Т.е. есть две кнопки, каждая обернута в двусторонний биндинг
atom<boolean>. Как изобразить условие, что при нажатии на свободную кнопку вторая должна быть отключена?Мне в качестве первого этапа собеседования в Nest (куплен Google) предложили придумать архитектуру небольшого проекта и снять "professional-looking" видео с рассказом о ней. Отказался.
Если интересно мое мнение, опыта у вас много, но читаете по профессии недостаточно)
При оценке быстродействия структур данных положено различать разные операции над ними и использовать o-нотацию. big data, map-reduce, сортировка в кластере, наверное, знакомы всем, кто активно интересуется современным IT. Самый простой способ решить такую задачу — сортировка слиянием (merge sort). Имхо, каждый уважающий себя программист должен прочитать хотя бы одну книжку по алгоритмам. Мне нравится вот эта: http://www.ozon.ru/context/detail/id/6290126/
Конечно, нельзя требовать знание всего этого с джуна… но кто сказал, что эти вопросы годятся только для него?)
Не статья, а просто какой-то кошмар работодателя. Расскажу со стороны собеседующего: разместили вакансию, и тут поперли косяком люди с красивыми резюме, но в программировании ни в зуб ногой. Почти всем хватило трех простых вопросов:
А на каждого надо тратить время...
видел. мне в нем очень не понравилось, что он позволяет тихо переопределить уже загруженный инстанс класса — т.е. если что-то будет объявлено в разных модулях дважды, я об этом так и не узнаю.
Во-первых, эмуляция оставляет желать лучшего, прежде всего, эмуляция устройств, сети и /proc.
Во-вторых, десятка стала шибко умной ОС, которая решает всё за пользователя. Не то чтобы это было плохо, но текущие реалии — вин10 безобразно много обращается к диску, когда ее не просят. Что делает линукс более производительной ОС.
В-третьих, перенос большого кол-ва драйверов в юзермод, это, конечно, концептуально круто, но заикания музыки и лаги переключения раскладки при сильной загрузке системы удручают. Не говоря уже о том, что, пока я сидел под вин10, я успел подзабыть что такое отзывчивый интерфейс — когда UI реагирует СРАЗУ после клика.
Проблемы хорошо расписаны тут, например: http://www.warski.org/blog/2011/04/di-in-scala-cake-pattern-pros-cons/
Эх, а я-то подумал, что решена проблема распознавания речи лектора.
А также
5) много дополнительного кода
6) сложно конфигурировать в рантайме, т.к все зависимости прописаны в коде
7) самое важное — сложно тестировать, т.к. запуск модуля с парой моков вместо реальных классов сделать очень непросто. Также подход с синглтонами усложняет параллельное тестирование
По моему опыту, самый оптимальный DI для больших проектов на скале — это Guice.
Вообще печально наблюдать, как академическое scala-сообщество наступает на уже отполированные Java/C++ программистами грабли. Что синглтоны — это плохо, что перегрузка операторов превращает программу в нечитабельное мессиво...
Ага, но если бы всё было так просто. Тестировать надо а) то, что сломается и б) то, что, сломавшись, нанесет наибольший ущерб. Обычный баланс качество/трудозатраты, и, чтобы его соблюсти, нужно уметь предсказывать будущее. Или иметь очень большой опыт.
Прежде всего компонент должен "работать" — т.е. быть пригодным для использования пользователем, пусть и с багами. Если он падает с ошибкой или не позволяет показать все данные, то на выходе получается принципиально не работающее приложение.
Имхо, при написании тестов на UI нужно почаще задавать себе вопрос "что именно мы хотим проверить". Для этого компонета я бы назвал самым важным тестом "он показывает все элементы, если поле фильтра пустое". Ключевое слово — "показывает".