Не столько показал, сколько объяснил, что наши аггрегаторы не из пальца высасываются или чего там ещё, а собираются из первоисточников - полных данных о вызовах с коммутаторов. А показывал потом уже внешнему аудитору, который проверял качество внутренних контроллей. Сперва он грозился сам, своими силами всё проверить, но похоже их айти-отдел отказался, когда им просто озвучили полный объём месячных данных и попросил просто на его глазах просчитать небольшой кусок часового трафика сравнивая промежуточные результаты с нашим отчётом.
На ходу. Точнее по ходу. Либо при постановке задачи ставятся рамки по используемым инструментам и ты начинаешь их осваивать, либо понимаешь, что тут необходимо не то, на чём ты привык работать последнее время. В основном это связано с другим языком программирования (на обеих руках не хватит пальцев для подсчёта языков, на которых я написал хоть несколько строчек), новым фреймворком, другой субд. Понимая основы работы всего этого перейти на что-то новое не так уж и сложно.
Раз была довольно забавная ситуация, когда имея под рукой одно из руководств по Oracle PL/SQL я за полдня на коленке соорудил скрипт агрегации данных, который выполнял работу в районе 10 минут. Аналогичный по функционалу скрипт, написанный "сертифицированным специалистом, прошедшим курсы" запускали на ночь, в свободное время и работал он несколько часов. Товарищ увлёкся курсорами, а я, лентяй, основные выборки сделал на чистом SQL.
Правда иногда приходилось и своё продавливать. В одном крупном телекоме для нашей задачи выделили сервер на Windows (у них все так работали). Я с психу поставил туда Cygwin и сделал всё на перле и awk-е (sort-ы sed-ы и т.п. не в счёт). В итоге, когда на нас попробовал наехать один из топов, которому не по душе пришлись наши результаты, озвученные у гендира, типа два "пришельца" обидели целый крутой отдел, то я просто показал техпроцесс и мы получили в ответ предложение дружить )
Старый кадровик понимал разницу между токарем и фрезеровщиком и знал про их разряды.
Современный ЭйчАр мнит себя всезнайкой, но на самом деле его уровень познаний в нынешних специальностях (особенной технических и тем более в АйТишных) намного ниже того кадровика. Фактически этот эйчар не ищет спеца, а заманивает всех подряд на собеседование, надеясь, что рано или поздно количество перейдёт в качество, ну и себе галочек понаставить - вон я сколько спецов вам нашёл, выбирай не хочу. Плюс порой желание взять стопроцентно готового спеца вместо грамотного обучаемого - вот такого поиска я не понимаю. Вам шашечки или ехать? Я за свою 30летнюю карьеру раз в 3-4-5 лет перестраиваюсь под новый круг задач, порой весьма кардинально, этот процесс происходит регулярно. Что самое интересное - на результат никто не жаловался.
Вы с животными видимо только по книжкам общались, да в зоопарке за решёткой видели?
Когда собака выкармливает котят или кошка щенков, система даёт сбой?
В быту кошки с собаками порой неплохо ладят.
А котёнок любит спину дыбить даже на руку — этому его кто учил?
На мой взгляд наличие на том конце ардуинки (или любого другого микроконтроллера) необходимо ещё и для того, чтобы, к примеру, шифровать передаваемые пакеты.
Вряд ли вам понравится, если живущий в соседней квартире кулхацкер вдруг начнёт управлять вашими жалюзи.
Извиняюсь, если кто-то уже озвучил, комментарии читал по диагонали.
Давайте только представим, что монтировать систему должен электрик ЖЭКа (пусть и продвинутый), а эксплуатировать человек, умеющий лишь постить сэлфи и тарелки с едой в Инстаграмм. Как говорит мой любимый шеф — система разработана программистом для программистов. В данном виде у неё нет ни малейшего коммерческого будущего, хотя задумка весьма интересная и красивая. Т.е. для себя и избранных хабровчан.
Автор начал с разработки финишных модулей и сильно увлёкся этой темой. В итоге — определённая перегруженность, а следовательно, увеличенное время разработки, более, чем необходимо. Задачи, решённые в процессе разработки интересные, но скорее с академической точки зрения, чем с практической.
Я бы предложил начать с управляющего центра, который будет общаться с конечным пользователем и работать с финишными модулями. Кстати, на него же можно возложить и программирование управляющих блоков. И не обязательно заморачиваться с разработкой интерпретатора байт-кодов и их загрузкой, можно просто грузить готовые программы. Плюс некоторые доработки по конструктиву.
Если всё расписывать более развёрнуто, получится отдельная статья. Возможно имеет смысл изложить все свои претензии и предложения, ибо в основе своей система понравилась, а главное — подсказала ряд идей.
P.S. Автору огромное спасибо за проделанный труд, и главное, за публикацию идеи. На мой взгляд, при определённой доработке напильником, проект весьма работоспособен, а главное — конкурентоспособен. Ибо прост и не дорог. Прост, в том числе и в плане установки-настройки (при условии доведения до ума вопроса простоты общения и, возможно, конструктива).
Лет 10 нечто подобное встраиваю во все свои резидентные демоны.
А идею подглядел в книге Робачевский А.М. «Операционная система UNIX», где коротко описано, как открепить демона от родителя-стартера.
Для самообразования можно выбрать что-то более полезное для себя и общества. А понимание принципов работы какой-либо оси через написание своей — тонкий извращенный метод. По общим принципам операционок есть довольно качественная литература (которую кстати желательно изучить и при написании своей), а детали, ньюансы работы у каждой системы свои и для их понимания надо изучать именно эту систему. Например для начала можно найти книжку «Ядро Linux» и воспользоваться ей — будет быстрее и эффективнее.
Попробуйте гибридный вариант. Индекс (b-дерево) порезать на последовательные куски, а адрес вершины каждого поддерева хранить в хэше. В качестве хэш-ключа можно взять N первых байт базового ключа. Правда длины кусков-веток могут сильно отличаться из-за нелинейного распределения множества значений ключа.
При решении подобной задачи я открывал до 100 потоков на 100 разных сайтов (пробовал и 200, но скорость это уже практически не влияло). Грузил за раз не более одной страницы с сайта. Ответы днс кэшировал внутри программы и хранил, пока сайт в работе. Плюс проверял еще одну фишку — при получении данных днс для нового сайта проверял, если аналогичный IP уже есть в кэше, новый сайт ставился в очередь ожидания, а в обработку поступал следующий из очереди. Т.е. старался придерживаться не только правила «один поток на сайт», но и «один поток на сервер». Для нескольких виртуальных серверов на одной машинке это не пройдет, но тут уже наука бессильна. По крайней мере мне решение такого вопроса не известно.
Насчет рандомного биржевого вы погорячились. При достаточном объеме статистики за длительный период все работает достаточно неплохо. Просто это игра вдолгую и барыши тут скромные, по сравнению со спекуляциями на текущих колебаниях. Но и риски влететь несравнимо меньше.
Просто люди жадные, хотят все и сейчас, ну и в итоге теряют все и сейчас. Биржа не терпит психов и идиотов.
Вот академическая полезность, считаю, присутствует. Пусть не весь проект, но отдельные рещения могут получить право на жизнь в качестве расширений программных продуктов или даже существующих операционок.
Самое главное почему-то все упускают — востребованность системы определяется наличием в ней востребованных приложений. И поэтому чаще поддерживать «старье» экономически выгодней. По этой же причине за бугром до сих пор живут тучи Cobol-программ на давно забытом, можно сказать мертвом (как латынь) языке.
Если эта ОСь родится и даже если она будет большой конфеткой, скажите, кому она будет нужна на рынке?
Технические идеи — это технические идеи. Но я не вижу как минимум бизнес-идеи.
Да. Такое возможно только при введении понятия транзакции и введения этого понятия в систему разработки программ для Фантома. А кто забыл коммитнуть свой результат — получит на выходе пшик и больше забывать не будет.
А никуда не денешься от подбирания и встраивания старых кусков. Операционки разрабатывались опираясь на существующую структуру железа. А она с тех пор практически не изменилась — проц+оперативка+внешнее хранилище. С появлением и развитием флэш-дисков внешнее хранилище будет все ближе к оперативке, но всеравно не догонит и структура эта будет сохраняться еще долго. Может что-то типа квантовых компьютеров изменит эту картинку, ну так для них и другая идеология построения систем будет разработана, на совершенно других логических принципах.
Не столько показал, сколько объяснил, что наши аггрегаторы не из пальца высасываются или чего там ещё, а собираются из первоисточников - полных данных о вызовах с коммутаторов. А показывал потом уже внешнему аудитору, который проверял качество внутренних контроллей. Сперва он грозился сам, своими силами всё проверить, но похоже их айти-отдел отказался, когда им просто озвучили полный объём месячных данных и попросил просто на его глазах просчитать небольшой кусок часового трафика сравнивая промежуточные результаты с нашим отчётом.
На ходу. Точнее по ходу.
Либо при постановке задачи ставятся рамки по используемым инструментам и ты начинаешь их осваивать, либо понимаешь, что тут необходимо не то, на чём ты привык работать последнее время.
В основном это связано с другим языком программирования (на обеих руках не хватит пальцев для подсчёта языков, на которых я написал хоть несколько строчек), новым фреймворком, другой субд. Понимая основы работы всего этого перейти на что-то новое не так уж и сложно.
Раз была довольно забавная ситуация, когда имея под рукой одно из руководств по Oracle PL/SQL я за полдня на коленке соорудил скрипт агрегации данных, который выполнял работу в районе 10 минут. Аналогичный по функционалу скрипт, написанный "сертифицированным специалистом, прошедшим курсы" запускали на ночь, в свободное время и работал он несколько часов. Товарищ увлёкся курсорами, а я, лентяй, основные выборки сделал на чистом SQL.
Правда иногда приходилось и своё продавливать. В одном крупном телекоме для нашей задачи выделили сервер на Windows (у них все так работали). Я с психу поставил туда Cygwin и сделал всё на перле и awk-е (sort-ы sed-ы и т.п. не в счёт). В итоге, когда на нас попробовал наехать один из топов, которому не по душе пришлись наши результаты, озвученные у гендира, типа два "пришельца" обидели целый крутой отдел, то я просто показал техпроцесс и мы получили в ответ предложение дружить )
Старый кадровик понимал разницу между токарем и фрезеровщиком и знал про их разряды.
Современный ЭйчАр мнит себя всезнайкой, но на самом деле его уровень познаний в нынешних специальностях (особенной технических и тем более в АйТишных) намного ниже того кадровика. Фактически этот эйчар не ищет спеца, а заманивает всех подряд на собеседование, надеясь, что рано или поздно количество перейдёт в качество, ну и себе галочек понаставить - вон я сколько спецов вам нашёл, выбирай не хочу.
Плюс порой желание взять стопроцентно готового спеца вместо грамотного обучаемого - вот такого поиска я не понимаю. Вам шашечки или ехать? Я за свою 30летнюю карьеру раз в 3-4-5 лет перестраиваюсь под новый круг задач, порой весьма кардинально, этот процесс происходит регулярно. Что самое интересное - на результат никто не жаловался.
Да вообще - подгорабельная тема )))
Когда собака выкармливает котят или кошка щенков, система даёт сбой?
В быту кошки с собаками порой неплохо ладят.
А котёнок любит спину дыбить даже на руку — этому его кто учил?
Вряд ли вам понравится, если живущий в соседней квартире кулхацкер вдруг начнёт управлять вашими жалюзи.
Давайте только представим, что монтировать систему должен электрик ЖЭКа (пусть и продвинутый), а эксплуатировать человек, умеющий лишь постить сэлфи и тарелки с едой в Инстаграмм. Как говорит мой любимый шеф — система разработана программистом для программистов. В данном виде у неё нет ни малейшего коммерческого будущего, хотя задумка весьма интересная и красивая. Т.е. для себя и избранных хабровчан.
Автор начал с разработки финишных модулей и сильно увлёкся этой темой. В итоге — определённая перегруженность, а следовательно, увеличенное время разработки, более, чем необходимо. Задачи, решённые в процессе разработки интересные, но скорее с академической точки зрения, чем с практической.
Я бы предложил начать с управляющего центра, который будет общаться с конечным пользователем и работать с финишными модулями. Кстати, на него же можно возложить и программирование управляющих блоков. И не обязательно заморачиваться с разработкой интерпретатора байт-кодов и их загрузкой, можно просто грузить готовые программы. Плюс некоторые доработки по конструктиву.
Если всё расписывать более развёрнуто, получится отдельная статья. Возможно имеет смысл изложить все свои претензии и предложения, ибо в основе своей система понравилась, а главное — подсказала ряд идей.
P.S. Автору огромное спасибо за проделанный труд, и главное, за публикацию идеи. На мой взгляд, при определённой доработке напильником, проект весьма работоспособен, а главное — конкурентоспособен. Ибо прост и не дорог. Прост, в том числе и в плане установки-настройки (при условии доведения до ума вопроса простоты общения и, возможно, конструктива).
Отправьте швейцарцам факс: «Бе-бе-бе! Мы это сделали!» :)
А идею подглядел в книге Робачевский А.М. «Операционная система UNIX», где коротко описано, как открепить демона от родителя-стартера.
Просто люди жадные, хотят все и сейчас, ну и в итоге теряют все и сейчас. Биржа не терпит психов и идиотов.
Если эта ОСь родится и даже если она будет большой конфеткой, скажите, кому она будет нужна на рынке?
Технические идеи — это технические идеи. Но я не вижу как минимум бизнес-идеи.