class Dog
def set_name( aName )
@myname = aName
end
def get_name
return @myname
end
def gav
return 'r-r-r-r!'
end
end
dog1 = Dog.new
puts(dog1.get_name)
puts(dog1.gav)
выводит:
nil
r-r-r-r!
То есть одна из самых трудноотлавливаемых ошибок (неиницализированная переменная) в Ruby вообще за ошибку, или хотя бы достойной предупреждения, не считается?
Странно, что даже не получил никаких предупреждений, просто
может наоборот, главная прекрасность C++ в том, что пишем абрстакции на STL, а при необходимости (критические участки, как правило) пишем как на asm, а то и просто делаем asm вставки? :)
Согласен, что пора бы закончить :) Но напоследок отвечу, без задавания вопросов
Насчет дизайна спорить и не стал бы, особенно учитывая, что практически все развитие языка от PHP3 до PHP6 (только по докам) на моих глазах происходило. А программировать я начинал на ассемблере 8080, когда он начал меня тормозить открыл для себя BASIC (никаких Visual или хотя бы Quick), потом так же Си и т.п. А для веба начинал на Си, потом открыл PHP3, удивительно вовремя (когда я понял, что в pHP 3 мне не хватает ООП) вышел (вернее, стал доступен на массовых хостингах) PHP4; когда и он стал меня тормозить, открыл CMS, относительно недавно PH5 и одновременно PHP-фреймворки, как раз когда понял, что CMS меня сильно ограничивают и заставляют писать ужасный код.
Почти наверняка я еще просто не почувствовал ограничений моих текущих (и осваиваемых) инструментов, но сдается мне, что к тому времени PHP6 и новые фреймвоки на его основе их снимут :) С одной стороны не очень хорошая тенденция, что фактически язык (стабильные, получившие широкое распространение «мажорные» версии) меня догоняет постоянно, вдруг вообще пути разойдутся, а с другой — большое количество популярных готовых решений и приложений на их основе, зачастую используемых людьми вообще далекими от программирования, которым сразу или через некоторое время требуется разовая (или периодическая с довольно большим периодом) «доработка напильником».
Насколько мне известно в мире Ruby/Python пользователи (серверные так сказать) или сами поддерживают решения (полностью свои, или «полуфабрикаты» на базе фреймворков, или готовые на базе CMS), или связаны уже постоянным сотрудничество с теми, кто им устанавливал, настраивал. Объявления на какой-нибудь бирже фрилансеров типа «Need to minor fix our Ruby script» вижу довольно редко. То есть спрос на этом рынке меньше намного, можно сказать на порядки (причем десятичные) и переходить на новые (для меня) языки мне кажется несколько опрометчиво.
Хотя совету попробовать последую, точнее уже следую, следя за этими топиками, и не просто читая, а и экспериментируя на локальном машине. Возможно и сменю мнение о PHP, но, скорее всего, даже не смотря на то, что буду считать его уродским, работать с ним придется еще очень долго, пока мои потенциальные заказчики не будут считать также, а их хостеры не обеспечат поддержку этих языков.
Главная проблема, имхо, ограниченные средства связки контент/html/css/браузер (да и ос сюда же можно отнести) для удобной индивидуальной (и ручной, и автоматической) настройки отображения сайтов. Почему-то дизайнер (а то и верстальщик) решает, в частности, какой ширины (и в каких единицах) пользователь должен видеть нужный ему контент, причем решает ничего не зная о оборудовании и предпочтениях пользователя, в лучшем случае исходя из данных статистики.
Но это проблема глобальная, пока же наиболее удобной лично для себя, как для пользователя, для «серьезного» текстового контента (статьи, посты на форумах и блогах с ответами/комментами и т. п.) считаю «продвинутую резиновую верстку», когда при малой ширине (те самые 55-60 символов, именно символов, не в пикселях или дюймах ширина) окна (на маленьких экранах, не растянутых окнах или при большом масштабе) основной текстовый контент занимает 100% ширины окна (с небольшими отступами), а сайдбар(ы) за границей окна справа (желательно) или ниже. А на больших размерах окна основной текст порядка 2/3 его ширины (правая треть под сайдбар(ы). Правда вот реализовать (это особенно с правым размещением сайдбара на маленьких окнах) без JS у меня не получается :( Правда я верстальщик-любитель, даже дилетант
Монитор 19" (ЭЛТ, то есть видимая область примерно 18"), разрешение обычное 1600х1200, браузер FF 3, наиболее удобное личное для меня:
— «теекст 3» (исправьте два «е»), левый нижний угол- когда сижу за компьютером — эргономика рабочего места ужасная, но на то есть свои причины
— «текст 2», когда читаю с дивана, но не идеальное, мало того, что масштабирование средствами браузера не работает, так и не нужные мне поля по бокам
Понравилась статья, и фраза «Он замечательный человек. И даже разрешает нам
пользоваться туалетом», по-моему, очень хорошо описывает современное положение дел в массовых UI :(
Думаю, что просто нужно предусмотреть в интерфейсах возможность отключения существующей функциональности, то есть то, что сейчас есть, чтобы работало по умолчанию (в том числе и в API), а дополнительными параметрами: на веб-морде — галочками или «радио» (возможно с сохранением их состояния в куки, чтобы если человек хочет знать, в чем он ошибается, то ему не нужно было бы каждый раз изменять дефолтные значения), в html можно GET параметрами, в XML вроде и так все есть, добавить только значения атрибутов 2 (или -1) со смыслом «проверить» (неплохо было бы еще сделать возможность текстовых значений атрибутов, например «correct», «ignore» и «check» ) и возвращать результат проверки в отдельных тегах
>Ну а с тем что устройство программ навязано внутренним устройством компьютеров, как не согласиться :-)
А хорошо ли это? Ладно времена CLI и ранних GUI, когда каждый байт памяти и цикл процессора приходилось экономить, ну а сейчас-то, утверждают, что улучшают UI добавляя красивости, но не изменяя функциональности (не всегда конечно, но в общем, по-моему эволюция массовых GUI идет по экстенсивному пути)
Наверное крик души о том, что все эти функции не встроены в его ОС и, наверняка, даже если я установлю в винде или убунту такую «объектную» ФС, то в окнах открытия файлов Writer'a (или Word'a), NetBeans'a (или Eclipse, или VS), FireFox (или Opera), Gimp'a (или Photoshop'a) я все равно увижу только то, что предлагают авторы программы, фреймворков, библотек и ОС (наверное в таком приоритете), нет стандартных средств даже для одной ОС, не говоря уж о кроссплатформенности
Вроде как ключ не обязательно заводит двигатель, насколько я знаю там трехпозиционный «тумблер»с позициями «выкл», «вкл», «завести». А так, наверное, специалист по интерфейсам сделал бы завод двигателя по нажатию педали газа или включению передачи (если нужно остаться в рамках традиционного управления), по крайней мере опциональной эту возможность сделал, то есть вы можете, если есть необходимость в «тонкой настройке» запустить двигатель вручную, а в общем случае нажать на педаль, и если движок не заведен, то он сначала заведется, возможно прогреется (опять-таки с возможностью пропустить этот этап, если точно знаете что делаете) и т. п.
не буду говорить про системы автоматического анализа изображений и поиска на основе запросов естественным языком :), но суть в том, что место вы знаете только потому, что сами сохраняли его в рамках «навязанной» (то есть единственно доступной) модели иерархической структуры каталогов и файлов, причем саму структуры вы разрабатывали самостоятельно. Вам не предложили выбор (или одновременное использование) других структур, например задать метки «серый уголок», «белый фон», а лучше заполнить атрибуты объекта, например,:
«серый уголок на белом фоне»: тип: {имя: изображение, объекты: [1: { что: уголок, цвет: серый, фон: белый, размеры: {единица: пиксель, ширина: 10, высота: 10 } ], изображение, формат: png, путь: /куда/то/там/, имя_файла: 'имя файла', метки: [серый, уголок, белый, фон], версия: 1.0, автор: cooper } и т. п. (использован синтаксис близкий к YAML :) ), причем список атрибутов вы можете редактировать самостоятельно, доступны они должны быть в любом приложении, естественно с удобными средствами заполнения, выбора, поиска и т.п. в любом продукте, от вызовов API до стандартных гуевых окошек открытия и закрытия файлов или выбора в браузере файла для аплоада на хабр :)
Наверное не стоит буквально воспринимать фразу про календарь. и в принципе у большинства современных ФС, насколько я знаю, иерархическая система каталогов является надстройкой над собственно системой хранения файлов (иногда интегрированной в ФС, а иногда реализованной прямо в ОС), файл — это объект одного типа, на который ссылается объект другого типа (каталог), а в никсах так и каталог является файлом. Да и никто не предлагает отказываться от каталогизации, но стоит, по-моему, задуматься должна ли каталогизация навязываться пользователю как зачастую единственная система упорядочивания его файлов? Особенно учитывая, что многие прикладные продукты предлагают альтернативы, причем не обязательные, а на выбор — вот прямо сейчас, нажал в браузере (FF3) Ctrl+D и вижу возможность сохранить закладку в дереве папок и одновременно назначить ей «метки», могу воспользоваться одной возможностью, могу другой, могу обеими, а могу вообще не пользоваться ни одной. Кому-то будет плохо, если на уровне ОС будут средства, позволяющие пускай даже сторонним разработчикам (разработчикам самой ОС оставим любимое ими «дерево»), писать «плагины» реализующие разные, но равноправные, структуры хранения и соглашения об именовании пользовательских данных? Причем с автоматической трансляцией имен из одного «пространства» в " другое", можно даже оставить классическое дерево, как минимально необходимый «реализуемый интерфейс» для трансляции. Но суть в том, чтобы ОС могла однозначно определить про какой объект пользовательских данных идет речь в любом своем интерфейсе, от API через CLI до стандартных окон открытия и сохранения файлов. Да даже придумывать особо ничего не надо, есть стандарты на URL и URI, многие ОС теми или иными средствами позволяют монтировать ресурсы на которые они ссылаются как часть ФС, но не прозрачно для пользователя, а главное все равно в итоге реализующих структуру каталогов в глаза пользователя
Со многим согласен, правда не с тонкостями реализации, календарь, имхо, должен быть вспомогательным средством поиска.
И, кстати, всеми «любимая» MS хотела реализовать «реляционную ФС» еще в Висте (если память не изменяет), но уже отказалась от этой идеи, проект WinFS, афаик, закрыт
в этом случае расширения нужны человеку (и то не факт, что именно расширения, возможно метаданные были бы удобнее), но беда в том, что расширения используются ОС (не всеми, но самой популярной на десктопах точно :) ) и софтом для определения типа файла, грубо говоря какой программой или подпрограммой его открывать.
ключ зажигания все-таки реализует функцию авторизации :) и краем уха слышал где-то (авто не моя тема абсолютно), что есть, как минимум, опытные образцы с реализацией этой функции по отпечатку пальца
class Dog
def set_name( aName )
@myname = aName
end
def get_name
return @myname
end
def gav
return 'r-r-r-r!'
end
end
dog1 = Dog.new
puts(dog1.get_name)
puts(dog1.gav)
выводит:
nil
r-r-r-r!
То есть одна из самых трудноотлавливаемых ошибок (неиницализированная переменная) в Ruby вообще за ошибку, или хотя бы достойной предупреждения, не считается?
Странно, что даже не получил никаких предупреждений, просто
Насчет дизайна спорить и не стал бы, особенно учитывая, что практически все развитие языка от PHP3 до PHP6 (только по докам) на моих глазах происходило. А программировать я начинал на ассемблере 8080, когда он начал меня тормозить открыл для себя BASIC (никаких Visual или хотя бы Quick), потом так же Си и т.п. А для веба начинал на Си, потом открыл PHP3, удивительно вовремя (когда я понял, что в pHP 3 мне не хватает ООП) вышел (вернее, стал доступен на массовых хостингах) PHP4; когда и он стал меня тормозить, открыл CMS, относительно недавно PH5 и одновременно PHP-фреймворки, как раз когда понял, что CMS меня сильно ограничивают и заставляют писать ужасный код.
Почти наверняка я еще просто не почувствовал ограничений моих текущих (и осваиваемых) инструментов, но сдается мне, что к тому времени PHP6 и новые фреймвоки на его основе их снимут :) С одной стороны не очень хорошая тенденция, что фактически язык (стабильные, получившие широкое распространение «мажорные» версии) меня догоняет постоянно, вдруг вообще пути разойдутся, а с другой — большое количество популярных готовых решений и приложений на их основе, зачастую используемых людьми вообще далекими от программирования, которым сразу или через некоторое время требуется разовая (или периодическая с довольно большим периодом) «доработка напильником».
Насколько мне известно в мире Ruby/Python пользователи (серверные так сказать) или сами поддерживают решения (полностью свои, или «полуфабрикаты» на базе фреймворков, или готовые на базе CMS), или связаны уже постоянным сотрудничество с теми, кто им устанавливал, настраивал. Объявления на какой-нибудь бирже фрилансеров типа «Need to minor fix our Ruby script» вижу довольно редко. То есть спрос на этом рынке меньше намного, можно сказать на порядки (причем десятичные) и переходить на новые (для меня) языки мне кажется несколько опрометчиво.
Хотя совету попробовать последую, точнее уже следую, следя за этими топиками, и не просто читая, а и экспериментируя на локальном машине. Возможно и сменю мнение о PHP, но, скорее всего, даже не смотря на то, что буду считать его уродским, работать с ним придется еще очень долго, пока мои потенциальные заказчики не будут считать также, а их хостеры не обеспечат поддержку этих языков.
Но это проблема глобальная, пока же наиболее удобной лично для себя, как для пользователя, для «серьезного» текстового контента (статьи, посты на форумах и блогах с ответами/комментами и т. п.) считаю «продвинутую резиновую верстку», когда при малой ширине (те самые 55-60 символов, именно символов, не в пикселях или дюймах ширина) окна (на маленьких экранах, не растянутых окнах или при большом масштабе) основной текстовый контент занимает 100% ширины окна (с небольшими отступами), а сайдбар(ы) за границей окна справа (желательно) или ниже. А на больших размерах окна основной текст порядка 2/3 его ширины (правая треть под сайдбар(ы). Правда вот реализовать (это особенно с правым размещением сайдбара на маленьких окнах) без JS у меня не получается :( Правда я верстальщик-любитель, даже дилетант
— «теекст 3» (исправьте два «е»), левый нижний угол- когда сижу за компьютером — эргономика рабочего места ужасная, но на то есть свои причины
— «текст 2», когда читаю с дивана, но не идеальное, мало того, что масштабирование средствами браузера не работает, так и не нужные мне поля по бокам
пользоваться туалетом», по-моему, очень хорошо описывает современное положение дел в массовых UI :(
А хорошо ли это? Ладно времена CLI и ранних GUI, когда каждый байт памяти и цикл процессора приходилось экономить, ну а сейчас-то, утверждают, что улучшают UI добавляя красивости, но не изменяя функциональности (не всегда конечно, но в общем, по-моему эволюция массовых GUI идет по экстенсивному пути)
«серый уголок на белом фоне»: тип: {имя: изображение, объекты: [1: { что: уголок, цвет: серый, фон: белый, размеры: {единица: пиксель, ширина: 10, высота: 10 } ], изображение, формат: png, путь: /куда/то/там/, имя_файла: 'имя файла', метки: [серый, уголок, белый, фон], версия: 1.0, автор: cooper } и т. п. (использован синтаксис близкий к YAML :) ), причем список атрибутов вы можете редактировать самостоятельно, доступны они должны быть в любом приложении, естественно с удобными средствами заполнения, выбора, поиска и т.п. в любом продукте, от вызовов API до стандартных гуевых окошек открытия и закрытия файлов или выбора в браузере файла для аплоада на хабр :)
И, кстати, всеми «любимая» MS хотела реализовать «реляционную ФС» еще в Висте (если память не изменяет), но уже отказалась от этой идеи, проект WinFS, афаик, закрыт