3. Мы провели дополнительное исследование. По его результатам среди всей аудитории, 65% абонентов выбрали бы опцию скорость в рамках которой не снижалась бы, а подключались небольшие пакеты скоростного трафика. Среди активных абонентов этот процент выше
Можно подробнее, каким образом было проведено данное исследование? Какой покрывался процент аудитории? Где можно увидеть результаты исследования? Насколько репрезентативной была выборка? Я например резко против дополнительных незапланированных плат за интернет. Для меня гораздо важнее стабильность и наличие связи пусть даже ценой снижения скорости.
Маркетологи билайна — гениальные люди… сначала придумали разрывы связи, если было использовано слишком мало трафика. Теперь фактически отменили безлимитные тарифы и приравняли их к пакетам трафика. Особенно «весело» это смотрится в случае 3G-роутера, который висит сам себе на втором этаже дачи и на котором, чтобы прочитать смски, надо зайти в специальный вэб-интерфейс, а сам по себе он никак о приходе смс не уведомляет. Теперь появилась реальная перспектива в самый неподходящий момент обнаружить отсутствие интернета и минус на счету вместо просто пониженной скорости. Большое человеческое вам за это спасибо…
Я искренне надеюсь, что другие операторы не кинутся перенимать столь положительный и прогрессивный опыт инноваций в области мобильного интернета…
И вот, на днях команда ученых NASA сочла принцип warp drive «теоретически выполнимым и стоящим дальнейших исследований». Даже более того, эти ученые пошли немного дальше предположений и создали в своей лаборатории научный прибор внутри которого им удалось получить, пусть и крошечные, но все же, «пузырьки» деформации пространства.
Никто не мешает продавать в день премьеры копию, в которой будет в служебной инфе в разных местах файла натыкано, что копия была продана такому-то пользователю… таким образом, чтобы отвязывание ее было достаточно нетривиальной задачей… и жестоко карать тех, кто будет такую копию выкладывать на торренты… потому что будет сразу понятно кто выложил.
Проблема в том, что редкого заказчика удается убедить, что он на самом деле хочет то, что имеется в стандартных компонентах… Обычно говорят «вот на сайте *** сделано так, надо чтобы у нас было наподобие»… или у них уже есть мегакрутые идеи своего дизайна и бизнес-логики, на которых они будут стоять до последнего. И тут варианты либо терять проект, либо, если заказчик готов за это платить, переписывать половину CMS под его нужды…
А с интеграцией с 1С — это извечный больной вопрос… я, правда, сталкивался с ней не на примере битрикса, а на примере UMI.CMS… про которую так же писали, что там интеграция «из коробки»… А выяснилось, что хотя и формат Commerce ML2 полностью документирован, но у различных версий 1С: Торговля данные формируются чуть по-разному… кроме того, далеко не все данные импортируются, не импортируются «Предложения»… я здесь даже выкладывал статью, как это дело поборол. Поэтому полностью согласен с тем, что надо интеграцию отдельно согласовывать на этапе утверждения проекта, особенно, если уже есть готовая база товаров.
Голосовой ввод — довольно нишевое средство. И универсальным ему не стать, как бы это не пророчили уже много лет. Например, модные сейчас «open space» офисы: если каждый будет вместо печати диктовать, будет хаос и никто не сможет работать. Дома очень распространена ситуация, когда родные спят, а хочется по-быстрому заглянуть на форум (в эху) и ответить. Будешь в этом случае пользоваться голосовым вводом? Естественно, нет. Далее, на улице будешь перекрикивать уличный шум и сообщать всем окружающим, что собираешься ответить? Нет. Поэтому никакой революции не ожидается…
Где голосовой ввод востребован (и начинает применяться уже сейчас)? Это, в первую очередь, работа с клиентами. Прием у врача, у любого другого специалиста, службы техподдержки и т.п. Где необходимо преобразовать в текст сообщение о проблеме (о симптомах заболевания), а в дальнейшем возможно уже воспользоваться технологиями экспертных систем и в ряде случаях оказать помощь даже без участия самого специалиста…
Если такая ситуация возникает часто — то это проблема не в комментариях, а в программистах. Ибо подобные товарищи сегодня забудут поменять комментарий, а завтра забудут проинициализировать переменную. Или еще что-нибудь забудут уже в коде. Так что это вопрос уже не в методологии оформления кода, а в уважении к товарищам по команде, которым в дальнейшем поддерживать подобный код с неактуальными либо отсутствующими комментариями.
Лично я придерживаюсь следующего подхода:
Когда комментарии не нужны? Когда код очевидный и самодокументируемый, по нему спокойно можно пробежать глазами, и сразу все понятно.
Когда комментарии нужны?
— Для автоматической генерации документации типа javadoc. Тот, кто будет читать эту документацию, не будет видеть перед глазами код, а будет видеть только документ, сгенерированый на основе комментариев. Иначе ему придется держать перед глазами еще и исходник, что сразу делает бессмысленым генерацию документации.
— При объявлении неочевидных констант, когда для объяснения смысла константы придется делать ее имя слишком длинным.
— Для пояснения каких-то деталей в коде, не связанных непосредственно с алгоритмом, но необходимых для адаптации к конкретному устройству или среде (например различных проверок, предположений, что вот здесь система будет вести себя определенным образом и т.п.).
— Для пояснения неочевидных алгоритмичесуих решений. Например с целью оптимизации.
Естественно, критерий «очевидности» у каждого свой в зависимости от опыта. Для кого-то деление побитовым сдвигом будет нуждаться в комментировании, для кого-то и сложные структуры данных и алгоритмы будут казаться очень легко читающимися и не нуждающимися в дальнейших пояснениях. Но стоит только помнить, что экономя свое время на написании комментария, ты отнимаешь его у коллеги, которому придется разбираться в твоем коде…
9. Потомков этого прибора не раз видел в строительных магазинах в отделах электротоваров. Там, когда заказываешь нужное число метров кабеля, его вставляют в measuregraph, протягивают провод через него, а на счетчике отображается нужный метраж…
Копирастические законы вообще далеки от здравого смысла… например у нас нельзя включить в торговом центре или маршрутке радио, несмотря на то, что музыка, которая идет по радио, уже лицензирована радиостанцией для публичного воспроизведения, и станция за нее заплатила правообладателям. Но тем не менее им все мало, и они хотят еще раз получить деньги за то же самое…
А теперь осталось только объяснить «рядовому юзеру», что это плохо… когда единственное что он понимает из написаного, что он не сможет позвонить родственникам, если он не обновится… и хорошо если еще хватит сообразительности позвать того кто понимает, а если не хватит? Или тот человек будет недоступен? Хорошо, когда есть кому следить за состоянием компа мамы, подруги, и т.д… но далеко не всегда все так радужно…
В плане программирования «широкоформатный» монитор удобен тем, что кроме непосредственно кода удобно по сторонам разместить еще:
— дерево файлов проекта либо список открытых фалов — это удобнее, чем список вкладок сверху, так позволяет держать перед глазами и переключаться на большее число файлов (например редактируется код, шаблон верстки и файлы локализации, при этом надо периодически обращаться к файлам из других проектов)
— дерево методов/переменных (у вас я смотрю SublimeText2, он справа отображает миниатюрное изображение файла исходника), но на мой взгляд, удобнее подход, когда справа выводится список методов либо узлов верстки, по которым осуществляешь навигацию. Это умеет не только Eclipse, но даже и Kate под линуксом.
Кроме того, часто в коде строки оказываются весьма длинными из-за длинных имен переменных либо классов в случае верстки. И оказывается что пространства по горизонтали не так уж и много…
Напоминает фантастический рассказ 1980 года — Дмитрий Биленкин Операция на совести, где тоже делали операцию на мозге «для коррекции мыслительной деятельности». Правда, автор автор ошибся в одном — в настоящее время для такой коррекции вовсе не нужно нейрохирургическое вмешательство — ее успешно заменяет зомбирование через ТВ, развлекательные сайты и т.п… А тех, кто посмеет выделяться из толпы, заметят сразу, возможно, даже при помощи «цифровой толпы» Мицгола…
> Ввиду того, что часто наши соотечественники криво верстают документы (видели бы вы некоторые отчеты — это ужас), а нужно было корректное отображение — начал пользоваться Microsoft Skydrive и их облачным офисом.
А каким образом вы работали со SkyDrive под Linux? Через вэб-интерфейс?
Интересно бы взглянуть на само это демо. Будет ли возможность запустить например TotalCommander, а из под него открыть множество приложений и расположить на экране несколько окон? Насколько все будет тормозить на ARM-планшетах, учитывая разную архитектуру? Так то новость очень многообещающая, так как полно чисто виндового софта, который не портировали никогда на Android, но который пригодился бы в работе…
Можно подробнее, каким образом было проведено данное исследование? Какой покрывался процент аудитории? Где можно увидеть результаты исследования? Насколько репрезентативной была выборка? Я например резко против дополнительных незапланированных плат за интернет. Для меня гораздо важнее стабильность и наличие связи пусть даже ценой снижения скорости.
Я искренне надеюсь, что другие операторы не кинутся перенимать столь положительный и прогрессивный опыт инноваций в области мобильного интернета…
А с интеграцией с 1С — это извечный больной вопрос… я, правда, сталкивался с ней не на примере битрикса, а на примере UMI.CMS… про которую так же писали, что там интеграция «из коробки»… А выяснилось, что хотя и формат Commerce ML2 полностью документирован, но у различных версий 1С: Торговля данные формируются чуть по-разному… кроме того, далеко не все данные импортируются, не импортируются «Предложения»… я здесь даже выкладывал статью, как это дело поборол. Поэтому полностью согласен с тем, что надо интеграцию отдельно согласовывать на этапе утверждения проекта, особенно, если уже есть готовая база товаров.
Где голосовой ввод востребован (и начинает применяться уже сейчас)? Это, в первую очередь, работа с клиентами. Прием у врача, у любого другого специалиста, службы техподдержки и т.п. Где необходимо преобразовать в текст сообщение о проблеме (о симптомах заболевания), а в дальнейшем возможно уже воспользоваться технологиями экспертных систем и в ряде случаях оказать помощь даже без участия самого специалиста…
Лично я придерживаюсь следующего подхода:
Когда комментарии не нужны? Когда код очевидный и самодокументируемый, по нему спокойно можно пробежать глазами, и сразу все понятно.
Когда комментарии нужны?
— Для автоматической генерации документации типа javadoc. Тот, кто будет читать эту документацию, не будет видеть перед глазами код, а будет видеть только документ, сгенерированый на основе комментариев. Иначе ему придется держать перед глазами еще и исходник, что сразу делает бессмысленым генерацию документации.
— При объявлении неочевидных констант, когда для объяснения смысла константы придется делать ее имя слишком длинным.
— Для пояснения каких-то деталей в коде, не связанных непосредственно с алгоритмом, но необходимых для адаптации к конкретному устройству или среде (например различных проверок, предположений, что вот здесь система будет вести себя определенным образом и т.п.).
— Для пояснения неочевидных алгоритмичесуих решений. Например с целью оптимизации.
Естественно, критерий «очевидности» у каждого свой в зависимости от опыта. Для кого-то деление побитовым сдвигом будет нуждаться в комментировании, для кого-то и сложные структуры данных и алгоритмы будут казаться очень легко читающимися и не нуждающимися в дальнейших пояснениях. Но стоит только помнить, что экономя свое время на написании комментария, ты отнимаешь его у коллеги, которому придется разбираться в твоем коде…
— дерево файлов проекта либо список открытых фалов — это удобнее, чем список вкладок сверху, так позволяет держать перед глазами и переключаться на большее число файлов (например редактируется код, шаблон верстки и файлы локализации, при этом надо периодически обращаться к файлам из других проектов)
— дерево методов/переменных (у вас я смотрю SublimeText2, он справа отображает миниатюрное изображение файла исходника), но на мой взгляд, удобнее подход, когда справа выводится список методов либо узлов верстки, по которым осуществляешь навигацию. Это умеет не только Eclipse, но даже и Kate под линуксом.
Кроме того, часто в коде строки оказываются весьма длинными из-за длинных имен переменных либо классов в случае верстки. И оказывается что пространства по горизонтали не так уж и много…
А каким образом вы работали со SkyDrive под Linux? Через вэб-интерфейс?