Хм… Честно говоря не понятно в чем крутизна. Все embedded устройства имеют так называемые технологические отладочные порты JTAG, SPI и прочая в зависимости от производителя камня. Процесс загрузки можно контролировать пошагово. При должном навыке пин-код вскрывается на раз-два-три. С Адроидом даже проще, там открытый код. С iOS сложнее, но после 3-4 раза это тоже станет дежурной процедурой.
Скорее не закрытом, а в кодированном виде. Кодируется, для возможности восстановления данных в случае ошибок приёма.
Повторная передача пакета информации с учётом времени прохождения сигналов очень дорогая операция…
Надеюсь вы в резюме не пишите сисадмин-эникейщик? Для hh, человек не уважающий свои навыки, плохая кандидатура. Тем более в такой сфере как IT. Для многих hh, айтишники это просто небожители. Если вы не впишетесь в их представление об айтишниках, то вы попадете в отстой.
Но часто hh вообще плевать на сколько качественного специалиста они поставят заказчику. Им главное, чтобы заказчик подписал акт выполненных работ. А для этого надо, чтобы кандидат тупо соответствовал формальным требованиям. И им даже по большому счёту всё равно наврали вы или нет. Это вы уже потом будете разбираться с работодателем. Они конечно пытаются отфильтровывать конкретный дрэг, но не более того.
Поэтому первый вариант, это что вам ниже советовали. Врать… На собеседовании нужно лишь правильно ответить на вопросы. И никогда не отвечать на вопросы, которые вам не задавали.
Если у вас всё в порядке с коммуникабельностью, то лучше выяснить название компании, которая ищет кандидата. И выходить напрямую на руководство ит-отдела, минуя их отдел кадров. Если вы их убедите в том, что вы тот человек который решит все их проблемы, то они вас сами отведут за руку в отдел кадров…
Я не против функций как объектов первого рода. Просто на мой взгляд это создает определенные и очевидные неудобства. Лишнее усложнение жизни программиста, которое можно было и не создавать.
Но возможно, это дает какой-то профит. Если это так, то хотелось бы примеров…
Вам ни о чем. Вы в этом не нуждаетесь, как я понимаю. Я просто комментировал статью. То, что я назвал это довольно важный функционал в ruby, без этого ruby как язык был бы значительно слабее.
В ruby тоже всё объект.
Общее пространство имен для функций и для переменных создает на мой взгляд довольно серьезные ограничения. А выгода, получается, только в том, что при написании интерпретатора нет необходимости создавать отдельную таблицу для имен функций, всё можно сваливать в одну кучу.
Или я не прав? Какие возможности это дает python'у?
Если я правильно понимаю, функция своим именем занимает имя в пространстве имен переменных. То есть код:
def func( a, b) :
return a + b
func = 1
func( a=1, b=2 )
выдаст ошибку. То есть программируя на python'е я должен следить, чтобы случайно не назвать переменную именем библиотечной функции, например.
Понятно. что питонисты это уже на автопилоте отслеживают, но назвать это хорошей идеей сложно.
Хотя бы потому, что случаи присваивания функции переменной это куда более редкая операция, чем просто присваивание числа переменной даже в python'е. Ради нечастой фичи приходится постоянно контролировать именование переменных.
Это проблема тормознутости майнтейнеров пакетов ruby в конкретных дистрах. В Archlinux'е свежий ruby в основном репозитории появляется максимум через неделю после официального анонса.
На счет болезненности перехода с 1.8 на 1.9 — чушь. Как тут ранее верно заметили, это касается перехода с рельс 2.х на 3.x. Но не рельсами едиными живо ruby, как говорится…
На счет многозадачности… В ruby майнстримом признана другая парадигма. Почитайте про fibers. Это что-то типа реализации кооперативной многозадачности внутри руби и является абсолютно переносимым решением.
Автор совсем ничего не сказал про метапрограммирование, duck-typing, встроенный фреймворк тестирования minitest (это для ruby 1.9) и прочая. А это в ruby «наше всё»… Впрочем, признаюсь, как с этим обстоят дела на питоне я вообще не в курсе. Возможно не хуже…
Всё-таки изрядно видно, что автор больше питонист, мышление у него явно не ruby-style.
Мне например, присваивать переменной функцию даже в голову не приходило. Для этого в руби используются лямбда-функции. Как никак это уже относится к функциональному программированию.
То как это сделано на питоне выглядит для меня как грязный хак.
Но за общий доброжелательный тон обзора — респект. Была бы возможность, плюсанул бы обязательно…
Были… Так называемые Океанографические исследовательские корабли с гиганскими шарами на верхних палубах. И три из них постоянно.курсировали в тихом, атлантическом и индийском океане. Все давно попилены на втормет…
Кстати, про теневую сторону. Мне не понятна ситуация (хотя на самом деле понятна) с телеметрией на теневой стороне. Фрагменты этой телеметрии умудряются принимать радиолюбители на свои приемники, собранные на коленках.
При нынешнем уровне развития электроники комплекс слежения и приема телеметрии во всеми устройствами обеспечения будет размером максимум с 5-тонный контейнер и стоимость его вряд ли будет принципиально больше миллиона рублей. Плюхнуть его на Кубе, например, ничего не будет стоить, учитывая их долги перед Россией.
Можно например отдать на аутсорсинг эту услугу. Если заранее сообщать время пусков и параметры орбиты, можно даже силами радиолюбителей организовать сбор телеметрии, пусть даже не в реальном времени.
Или учитывая суммы страховых взносов, я думаю даже страховая компания страхующая пуски, легко сможет оплатить содержание такой станции.
В общем цена вопроса мизерная по сравнению со стоимостью потерянных спутников.
Тем не менее официальные лица Роскосмоса и ГПКС'а продолжают нести бред про отсутствие телеметрии на «той» стороне.
У меня есть стойкое убеждение, что это вранье и что на самом деле телеметрия есть. Но это, очевидно, частная информация, и не удивлюсь, если она является предметом отдельного бизнеса.
Да даже НПО Лавочкина могло бы само организовать сбор информации, чтобы не собирать все шишки на себя.
Полагаю, это что должен сделать любой руководитель Роскосмоса, придя на свое место, чтобы обеспечить прикрыть своей задницы.
Хотя… Судя по прессе у них там на повестке дня куда более серьезные вопросы. Например, там 6 или 7 марта мужики выясняли, кто первый будет «мацать» пресс-секретаря…
Ничего не понял про подключение новых блоков питания, которые "… автоматически распознают подключение и позволяют задавать жесткие рамки по расходованию электричества каждым сервером. Электроэнергия распределяется автоматически, что снимает потребность в ручном конфигурировании, при котором часто происходят ошибки. "
Какие ошибки имеются ввиду? Что именно приходилось раньше конфигурировать в ручную? И про задание жёстких рамок — то есть, если системе понадобилась вдруг максимальная производительность и соответственно тактовая частота и потребление энергии, то блок питания её «обломает»?
Я с уважением отношусь к hp и её продукции, но ролик и «брошюрка» ссылка на которую приведена выше у меня оставили ощущение фрустрации.
Похоже я ничего не понимаю в тенденциях, но:
Мне страшном сне не приснится, что сервера без моего ведома будут самостоятельно лить непонятно какую информацию через публичную сеть производителю. Особенно если серверы заняты обработкой сколь-либо серьезной информации, а не хранением порнографии, пардон…
Обновлять микрокод и прошивки биоса на «боевых» серверах без насущной необходимости, только потому, что производитель захотел, испокон веку считалось моветоном и признаком крайнего непрофессионализма администратора.
Не могу представить, чтобы вменяемый администратор ЦОДа (если конечно он не работник hp) будет получать уведомления iPhone через Insight Remote Support. (И вообще, администратор с iPhone?! Но это уже моё личное… ) Предполагается, что в ЦОДы без нормального внутреннего оповещения это нормально?
Окей. Если это не ЦОД, и у заказчика хватило денег на нормальный сервер каковым является Gen8, то уж на нормального админа, который может настроить нормальную систему оповещения без того, чтобы эти оповещения не летали через весь земной шар и штаб-квартиру hp, должно точно хватить.
Я правильно понимаю, что теперь обращения в службу саппорта hp по поводу проблем с серверами, должны стать нормальным явлением?
Это что, теперь новые «высокие» стандарты администрирования, продвигаемые hp?
На моей практике сервера hp всегда отличались беспроблемностью (относительной), но посмотрев эти материалы, что-то я здорово напрягся…
Видимо крупные зарубежные операторы таки уелись монополии производителей оборудования для сотовых сетей GSM. Экономика вопроса очевидна:
1) Требуемый объем «станционного оборудования» автоматом переводит это оборудование в разряд массового. Что автоматом приводит к снижению стоимости. Про оборудование для макросот всё понятно. Сейчас стоимость смонтированной БС GSM/3G в сборе от миллиона и дальше…
2) Упрощенная процедура легализации маломощного оборудования микросот в масштабе федерального оператора дает серьезную выгоду как по срокам ввода в эксплуатацию так и по затратам. Мощные передатчики макросот всегда будут проблемой в плане легализации. А иногда легализацию можно и не получить, если военные упрутся. А они упрутся… В нашей стране количество аффилированных с вояками структур лезущих на рынок мобильной и не только связи уже начинает превышать разумные пределы. Конфликты с вояками по части частот LTE у нас уже во всю идут…
3) Микросоты позволяют гибко управлять плотностью сетей. Более того, если стоимость БС микросоты существенно снизится, то затраты на это оборудование можно будет переложить на собственников территорий, зданий и/или помещений. В США это уже обычная практика…
Ну и так далее… Нет ни одного вменяемого аргумента за поддержание технологии макросот, кроме необходимости соответствовать существующим сетям…
М-да… То, что забивает кеш это фиг с ним. Кому надо уменьшат размер кеша до приемлемых для них величин.
А вот то, что он по заполнении кеша отказывает другим приложениям вместо того, чтобы выбрасывать самый старый чейн, это серьезный косяк. Это означает что одно web-приложение может повлиять на нормальную работу другого приложения.
Собственно так и есть. СoachDB, например, на этом принципе и построен.
На примере веб-сервисов: Развитие js-фреймворков зачастую делает слой контроллера и view'а на стороне сервера лишним.
То, что делает контроллер и view, легко может сделать js-фреймворк на клиентской стороне: Запросить данные в виде json, преобразовать к виду, удобному для представления и отобразить соответстующим образом.
В вашем случае, если api и отдача данных в формате json первична по отношению к функционалу отображения данных средствами сервера, то может и действительно rails избыточный инструмент.
:) Мой совет: Делайте декомпозицию структур, чтобы они были простыми и понятными. Принципиально упростить решение у вас вряд ли получится, но облегчить себе жизнь хоть как-то можно.
Лучше иметь много простых но легко понимаемых по отдельности структур, чем иметь две-три таких, в которых сам чёрт ногу сломит. Ведь чтобы состыковаться с вашим приложением, вашему коллеге придется с этим разбираться. Если он не сможет разобраться, то долбать он будет вас. )
То, что выбран JSON я как раз считаю правильным решением. Приятно удивлен тем, что не SOAP. В банковской среде это гм… очень любят и даже восторгаются им…
На счет свопа. Может быть и о сотнях мегабайтах, в статье об этом ничего не говорится.
И потом, редкая клиентская машина может похвастаться тем, что там выполняется только одно приложение. Даже в банкоматах обычно вертится больше одной задачи. Поэтому вполне возможен и своп.
В любом случае аллокация дополнительной памяти для приложения это достаточно дорогая задача. Не зря даже в наше время многие приложения грешат захватом памяти «про запас».
К чему эти фокусы не очень понятно…
Повторная передача пакета информации с учётом времени прохождения сигналов очень дорогая операция…
Видимо стоимость проекта им очень нравится…
Но часто hh вообще плевать на сколько качественного специалиста они поставят заказчику. Им главное, чтобы заказчик подписал акт выполненных работ. А для этого надо, чтобы кандидат тупо соответствовал формальным требованиям. И им даже по большому счёту всё равно наврали вы или нет. Это вы уже потом будете разбираться с работодателем. Они конечно пытаются отфильтровывать конкретный дрэг, но не более того.
Поэтому первый вариант, это что вам ниже советовали. Врать… На собеседовании нужно лишь правильно ответить на вопросы. И никогда не отвечать на вопросы, которые вам не задавали.
Если у вас всё в порядке с коммуникабельностью, то лучше выяснить название компании, которая ищет кандидата. И выходить напрямую на руководство ит-отдела, минуя их отдел кадров. Если вы их убедите в том, что вы тот человек который решит все их проблемы, то они вас сами отведут за руку в отдел кадров…
Но возможно, это дает какой-то профит. Если это так, то хотелось бы примеров…
В ruby тоже всё объект.
Общее пространство имен для функций и для переменных создает на мой взгляд довольно серьезные ограничения. А выгода, получается, только в том, что при написании интерпретатора нет необходимости создавать отдельную таблицу для имен функций, всё можно сваливать в одну кучу.
Или я не прав? Какие возможности это дает python'у?
выдаст ошибку. То есть программируя на python'е я должен следить, чтобы случайно не назвать переменную именем библиотечной функции, например.
Понятно. что питонисты это уже на автопилоте отслеживают, но назвать это хорошей идеей сложно.
Хотя бы потому, что случаи присваивания функции переменной это куда более редкая операция, чем просто присваивание числа переменной даже в python'е. Ради нечастой фичи приходится постоянно контролировать именование переменных.
На счет многозадачности… В ruby майнстримом признана другая парадигма. Почитайте про fibers. Это что-то типа реализации кооперативной многозадачности внутри руби и является абсолютно переносимым решением.
Автор совсем ничего не сказал про метапрограммирование, duck-typing, встроенный фреймворк тестирования minitest (это для ruby 1.9) и прочая. А это в ruby «наше всё»… Впрочем, признаюсь, как с этим обстоят дела на питоне я вообще не в курсе. Возможно не хуже…
Всё-таки изрядно видно, что автор больше питонист, мышление у него явно не ruby-style.
Мне например, присваивать переменной функцию даже в голову не приходило. Для этого в руби используются лямбда-функции. Как никак это уже относится к функциональному программированию.
То как это сделано на питоне выглядит для меня как грязный хак.
Но за общий доброжелательный тон обзора — респект. Была бы возможность, плюсанул бы обязательно…
При нынешнем уровне развития электроники комплекс слежения и приема телеметрии во всеми устройствами обеспечения будет размером максимум с 5-тонный контейнер и стоимость его вряд ли будет принципиально больше миллиона рублей. Плюхнуть его на Кубе, например, ничего не будет стоить, учитывая их долги перед Россией.
Можно например отдать на аутсорсинг эту услугу. Если заранее сообщать время пусков и параметры орбиты, можно даже силами радиолюбителей организовать сбор телеметрии, пусть даже не в реальном времени.
Или учитывая суммы страховых взносов, я думаю даже страховая компания страхующая пуски, легко сможет оплатить содержание такой станции.
В общем цена вопроса мизерная по сравнению со стоимостью потерянных спутников.
Тем не менее официальные лица Роскосмоса и ГПКС'а продолжают нести бред про отсутствие телеметрии на «той» стороне.
У меня есть стойкое убеждение, что это вранье и что на самом деле телеметрия есть. Но это, очевидно, частная информация, и не удивлюсь, если она является предметом отдельного бизнеса.
Да даже НПО Лавочкина могло бы само организовать сбор информации, чтобы не собирать все шишки на себя.
Полагаю, это что должен сделать любой руководитель Роскосмоса, придя на свое место, чтобы обеспечить прикрыть своей задницы.
Хотя… Судя по прессе у них там на повестке дня куда более серьезные вопросы. Например, там 6 или 7 марта мужики выясняли, кто первый будет «мацать» пресс-секретаря…
Какие ошибки имеются ввиду? Что именно приходилось раньше конфигурировать в ручную? И про задание жёстких рамок — то есть, если системе понадобилась вдруг максимальная производительность и соответственно тактовая частота и потребление энергии, то блок питания её «обломает»?
Я с уважением отношусь к hp и её продукции, но ролик и «брошюрка» ссылка на которую приведена выше у меня оставили ощущение фрустрации.
Похоже я ничего не понимаю в тенденциях, но:
Мне страшном сне не приснится, что сервера без моего ведома будут самостоятельно лить непонятно какую информацию через публичную сеть производителю. Особенно если серверы заняты обработкой сколь-либо серьезной информации, а не хранением порнографии, пардон…
Обновлять микрокод и прошивки биоса на «боевых» серверах без насущной необходимости, только потому, что производитель захотел, испокон веку считалось моветоном и признаком крайнего непрофессионализма администратора.
Не могу представить, чтобы вменяемый администратор ЦОДа (если конечно он не работник hp) будет получать уведомления iPhone через Insight Remote Support. (И вообще, администратор с iPhone?! Но это уже моё личное… ) Предполагается, что в ЦОДы без нормального внутреннего оповещения это нормально?
Окей. Если это не ЦОД, и у заказчика хватило денег на нормальный сервер каковым является Gen8, то уж на нормального админа, который может настроить нормальную систему оповещения без того, чтобы эти оповещения не летали через весь земной шар и штаб-квартиру hp, должно точно хватить.
Я правильно понимаю, что теперь обращения в службу саппорта hp по поводу проблем с серверами, должны стать нормальным явлением?
Это что, теперь новые «высокие» стандарты администрирования, продвигаемые hp?
На моей практике сервера hp всегда отличались беспроблемностью (относительной), но посмотрев эти материалы, что-то я здорово напрягся…
1) Требуемый объем «станционного оборудования» автоматом переводит это оборудование в разряд массового. Что автоматом приводит к снижению стоимости. Про оборудование для макросот всё понятно. Сейчас стоимость смонтированной БС GSM/3G в сборе от миллиона и дальше…
2) Упрощенная процедура легализации маломощного оборудования микросот в масштабе федерального оператора дает серьезную выгоду как по срокам ввода в эксплуатацию так и по затратам. Мощные передатчики макросот всегда будут проблемой в плане легализации. А иногда легализацию можно и не получить, если военные упрутся. А они упрутся… В нашей стране количество аффилированных с вояками структур лезущих на рынок мобильной и не только связи уже начинает превышать разумные пределы. Конфликты с вояками по части частот LTE у нас уже во всю идут…
3) Микросоты позволяют гибко управлять плотностью сетей. Более того, если стоимость БС микросоты существенно снизится, то затраты на это оборудование можно будет переложить на собственников территорий, зданий и/или помещений. В США это уже обычная практика…
Ну и так далее… Нет ни одного вменяемого аргумента за поддержание технологии макросот, кроме необходимости соответствовать существующим сетям…
А вот то, что он по заполнении кеша отказывает другим приложениям вместо того, чтобы выбрасывать самый старый чейн, это серьезный косяк. Это означает что одно web-приложение может повлиять на нормальную работу другого приложения.
Хотелось бы знать как с этим в других бровзерах…
На примере веб-сервисов: Развитие js-фреймворков зачастую делает слой контроллера и view'а на стороне сервера лишним.
То, что делает контроллер и view, легко может сделать js-фреймворк на клиентской стороне: Запросить данные в виде json, преобразовать к виду, удобному для представления и отобразить соответстующим образом.
В вашем случае, если api и отдача данных в формате json первична по отношению к функционалу отображения данных средствами сервера, то может и действительно rails избыточный инструмент.
Лучше иметь много простых но легко понимаемых по отдельности структур, чем иметь две-три таких, в которых сам чёрт ногу сломит. Ведь чтобы состыковаться с вашим приложением, вашему коллеге придется с этим разбираться. Если он не сможет разобраться, то долбать он будет вас. )
То, что выбран JSON я как раз считаю правильным решением. Приятно удивлен тем, что не SOAP. В банковской среде это гм… очень любят и даже восторгаются им…
И потом, редкая клиентская машина может похвастаться тем, что там выполняется только одно приложение. Даже в банкоматах обычно вертится больше одной задачи. Поэтому вполне возможен и своп.
В любом случае аллокация дополнительной памяти для приложения это достаточно дорогая задача. Не зря даже в наше время многие приложения грешат захватом памяти «про запас».