Было бы очень интересно услышать о том, каково именно вам жить с разрешением 800х480. Расскажите, пожалуйста, про свои впечатления, про то, как вы этот девайс используете, что нравится, а что нет. Удобно ли пользоваться, например, firefox или openoffice.
ПС: Рассматриваю покупку подобного устройства только с целью установки туда именно десктопного линукса. Поэтому очень хочется услышать именно такие отзывы
Юзер сам должен отметить, что это комментарий не по теме.
Если же юзер забудет — такая фича должна быть у автора поста — отметить комент как «не по теме».
Вот тут встает вопрос, что злые авторы топиков могут неуместные комментарии отправлять во вкладку «не по теме». Но за этим, я думаю, может следить отдельный алгоритм. тут еще надо подумать.
Я давненько думал про то, что перемешивание комментариев по теме поста и комментарии по оформлению текста этого поста портят общее впечатление. Мне, например, не хочется наблюдать объёмистую ветку коментов типа «ЖИ-ШИ пиши через И», «почему вы не подсветили код», «под кат пожалуйста», «картинка с imageshack больше не грузится» и так далее. А особенно неприятно, когда отъявленные чистоплюи начинают обливать автора бранью, мол, зря вас из школы выпустили с таким русским языком.
Поэтому предлагаю разработчикам хабра выделить два потока для комментариев: «по теме» и «по оформлению». Я вижу это как две вкладки перед деревом комментариев: по умолчанию, разумеется, выбрана вкладка «по теме». Технически, мне кажется, это проще сделать с помощью javascript, когда комменты «по оформлению» при загрузке страницы вырезаются из основного дерева и кладутся в отдельню вкладку. И еще придется добавить один чекбокс к форме комментария.
Нифига подобного! Нельзя phpDoc-ом сделать так, чтобы после
$this->load->model('megamodel');
$this->megamodel->[Ctrl+Space]
выпадал автокомплит методов класса megamodel
У меня не новый ноутбук на селероне и 770 мб памяти.
Да — тормозит само приложение
Да — притормаживает вся ось
Но это качественное приложение, на данный момент полностью покрывающее мои потребности и потребности подавляющего числа разработчиков. Уж неверняка лучше потерпеть, чем тыкаться в «летающие» но малофункциональные, а иногда и убогие программки.
К тому же блин… цена оперативки в магазине несравнимо меньше цены профитов при использовании удобных программ.
Visual Paradigm for UML Community Edition
Бесплатна к использованию, написана на Java, я использовал её и на винде, и под линуксом.
Community Edition — самая простая версия, но ее функционал в разы больше то же Umbrello или Dia.
Также есть один ньюанс для Community Edition: если, например, у вас одна диаграмма классов, то она нормально экспортируется в картинку или pdf, но если диаграммы две и больше — то поверх сэкспортированного изображения (или pdf) будут навязчивые водяные знаки, мол хочешь нормальное экспортирование — покупай. Такие же ограничения на все типы диаграмм.
Сначала меня это сильно удручило, но потом я придумал немного хакерский прием.
1. экспортируем диаграмму в изображение формата SVG
2. открываем SVG файл в текстовом редакторе (это же по сути XML файл, где вся информация, в том числе и водяные знаки написаны текстом) и удаляем кучу строк с описаниями водяных знаков, благо они не разбросаны по файлу, а находятся в самом конце.
3. качаем Batik SVG Toolkit и одной командой в шелле получаем чистенькие PDF или PNG. Batik тоже на Java, я использовал его на винде, но и на лине тоже должен запуститься.
Удобней экспортировать всегда в одну и ту же папку несколько svg файлов и натравливать batik на всю папку сразу с помощью одного и того же шелл скрипта.
Если диаграмма большая, то batik-rasterizer.jar следует запускать с указанием размера памяти под java, так как 64МБ по умолчанию бывает мало и тогда batik падает.
Кстати в самой Visual Paradigm for UML для генерирования PDF также используется Batik.
И еще в догонку: Visual Paradigm for UML не запустится под линуксом, если включен Compiz. Я справился так: поставил Compiz Fusion Tray Icon и каждый раз переключался между Compiz и Metacity. Неудобно, но можно потерпеть
во-во!
Бывает, что некоторые люди всегда тебе присылают письмо как как reply на одно из твоих старых писем, но тема может быть совсем не той, что в предыдущих.
С другой стороны, человек может написать тебе письмо как продолжение вашей переписки, но отправить его как новое.
Итог: цепочки не всегда работают именно так, как задумывались.
Пожеление: вручную разъединять цепочки или вручную собирать письма в цепочку.
Еще пожелание: правила объединения отдельных писем в цепочки можно было бы запихивать в фильтр.
Вот смотрю и вижу, что большинство комментариев негативные.
А теперь мой ряд вопросов разочаровавшимся в новости:
1. Разве вы делаете развесистый и пиксель-в-пиксель дизайн для кпк? — скорее всего нет, ибо кпк версия должна быть простой и четко структурированной, чтобы юзер смог сориентироваться на странице на маленьком экране. Красота для кпк наводится в основном шрифтами и бэкграундами.
2. Когда вы боролись с ИЕ6 при верстке? — наверняка не в случаях с простыми css эффектами, обозначенными выше, а при указании позиционирования элементов. С позиционированием на маленьком экране особо не развернешься.
Вывод, по-моему, очевиден: движок ИЕ6 в покетах на WM — это очень хорошо.
Да, и еще, не забудьте что уже у вас в распоряжении куча методов борьбы с ИЕ6 не декстопах, которые, наверняка, с небольшими изменениями перекочуют на покеты.
Радуйтесь!
Я взял от CI:
1) подхватывание контроллеров из ЧПУ + возможность ре-роутинга урлов,
2) обертку над БД (пишу чистый SQL, active record не использую)
3) классы для логирования и профилирования
С этими вещами еще не разбирался, но выглядят привлекательно:
4) примочки типа базового фильтрования на предмет xss, простой типограф, еще некоторые хелперы
5) классы для доступа к ftp и xml-rpc
6) классы для отправления email, работы с сессиями, работы с календарем
7) класс-листалка, класс-простенький манипулятор над изображениями
Возможно пункты из второго списка себя не оправдают, так как в интернете достаточно много других классов, написанных с теми же целями, которые вероятно покажут себя лучше.
С хелперами для построения форм или таблиц я вообще не собираюсь связываться — это точно здец, плюс у меня объекты будут сами мапиться в формы и обратно.
Класс валидации форм оказался для меня очень простеньким, буду делать свою реализацию.
Кеширование в CI немного не такое, какое мне нужно, тоже будем писать своё.
Чего мне не хватало и я написал это сам:
1) реализация паттернов Registry и IdentityMap
2) мне нужны data-mapper`ы, как раз над ними работаю
Врезать в CI свою функцию __autoload() не составило никакого труда, так же как и пользоваться своими классами, сложенными в отдельную папочку рядом с CI. Писать свои классы как CI-библиотеки или плагины нет никакого желания, пусть они будут от него независимыми.
Итог:
1) CI дал мне несколько удобных вещей, которые мне пришлось бы реализовывать самостоятельно. Вещи эти достаточно базовые и пере-затачивание их от проекта к проекту не требуется
2) необходимые вещи я спокойно добавил в CI, трудностей не возникло
3) в CI есть вещи, которые мне не нужны или не устраивают меня, или даже бесят, но они лежат себе в файликах и меня не колышат.
Вывод:
CI вам предоставляет свой инструментарий но не ограничивает вас в его расширении сторонними разработками. Пользуйтесь ровно тем, что вам надо, на остальное забейте.
Всегда преклоняюсь перед теми, кто сумел прикрутить что-то одно к чему-то другому, да так, что это никому раньше в голову не приходило, плюс это бы работало и притом элегантно и эффективно!
---
Сорри, если сумбурно изложил мысль => ночь+усталость
спасибо за такое полезное сведение.
ПС: Рассматриваю покупку подобного устройства только с целью установки туда именно десктопного линукса. Поэтому очень хочется услышать именно такие отзывы
Если же юзер забудет — такая фича должна быть у автора поста — отметить комент как «не по теме».
Вот тут встает вопрос, что злые авторы топиков могут неуместные комментарии отправлять во вкладку «не по теме». Но за этим, я думаю, может следить отдельный алгоритм. тут еще надо подумать.
Поэтому предлагаю разработчикам хабра выделить два потока для комментариев: «по теме» и «по оформлению». Я вижу это как две вкладки перед деревом комментариев: по умолчанию, разумеется, выбрана вкладка «по теме». Технически, мне кажется, это проще сделать с помощью javascript, когда комменты «по оформлению» при загрузке страницы вырезаются из основного дерева и кладутся в отдельню вкладку. И еще придется добавить один чекбокс к форме комментария.
Как вам такая идея?
$this->load->model('megamodel');
$this->megamodel->[Ctrl+Space]
выпадал автокомплит методов класса megamodel
Да — тормозит само приложение
Да — притормаживает вся ось
Но это качественное приложение, на данный момент полностью покрывающее мои потребности и потребности подавляющего числа разработчиков. Уж неверняка лучше потерпеть, чем тыкаться в «летающие» но малофункциональные, а иногда и убогие программки.
К тому же блин… цена оперативки в магазине несравнимо меньше цены профитов при использовании удобных программ.
Бесплатна к использованию, написана на Java, я использовал её и на винде, и под линуксом.
Community Edition — самая простая версия, но ее функционал в разы больше то же Umbrello или Dia.
Также есть один ньюанс для Community Edition: если, например, у вас одна диаграмма классов, то она нормально экспортируется в картинку или pdf, но если диаграммы две и больше — то поверх сэкспортированного изображения (или pdf) будут навязчивые водяные знаки, мол хочешь нормальное экспортирование — покупай. Такие же ограничения на все типы диаграмм.
Сначала меня это сильно удручило, но потом я придумал немного хакерский прием.
1. экспортируем диаграмму в изображение формата SVG
2. открываем SVG файл в текстовом редакторе (это же по сути XML файл, где вся информация, в том числе и водяные знаки написаны текстом) и удаляем кучу строк с описаниями водяных знаков, благо они не разбросаны по файлу, а находятся в самом конце.
3. качаем Batik SVG Toolkit и одной командой в шелле получаем чистенькие PDF или PNG. Batik тоже на Java, я использовал его на винде, но и на лине тоже должен запуститься.
Удобней экспортировать всегда в одну и ту же папку несколько svg файлов и натравливать batik на всю папку сразу с помощью одного и того же шелл скрипта.
Если диаграмма большая, то batik-rasterizer.jar следует запускать с указанием размера памяти под java, так как 64МБ по умолчанию бывает мало и тогда batik падает.
Кстати в самой Visual Paradigm for UML для генерирования PDF также используется Batik.
И еще в догонку: Visual Paradigm for UML не запустится под линуксом, если включен Compiz. Я справился так: поставил Compiz Fusion Tray Icon и каждый раз переключался между Compiz и Metacity. Неудобно, но можно потерпеть
Бывает, что некоторые люди всегда тебе присылают письмо как как reply на одно из твоих старых писем, но тема может быть совсем не той, что в предыдущих.
С другой стороны, человек может написать тебе письмо как продолжение вашей переписки, но отправить его как новое.
Итог: цепочки не всегда работают именно так, как задумывались.
Пожеление: вручную разъединять цепочки или вручную собирать письма в цепочку.
Еще пожелание: правила объединения отдельных писем в цепочки можно было бы запихивать в фильтр.
А теперь мой ряд вопросов разочаровавшимся в новости:
1. Разве вы делаете развесистый и пиксель-в-пиксель дизайн для кпк? — скорее всего нет, ибо кпк версия должна быть простой и четко структурированной, чтобы юзер смог сориентироваться на странице на маленьком экране. Красота для кпк наводится в основном шрифтами и бэкграундами.
2. Когда вы боролись с ИЕ6 при верстке? — наверняка не в случаях с простыми css эффектами, обозначенными выше, а при указании позиционирования элементов. С позиционированием на маленьком экране особо не развернешься.
Вывод, по-моему, очевиден: движок ИЕ6 в покетах на WM — это очень хорошо.
Да, и еще, не забудьте что уже у вас в распоряжении куча методов борьбы с ИЕ6 не декстопах, которые, наверняка, с небольшими изменениями перекочуют на покеты.
Радуйтесь!
1) подхватывание контроллеров из ЧПУ + возможность ре-роутинга урлов,
2) обертку над БД (пишу чистый SQL, active record не использую)
3) классы для логирования и профилирования
С этими вещами еще не разбирался, но выглядят привлекательно:
4) примочки типа базового фильтрования на предмет xss, простой типограф, еще некоторые хелперы
5) классы для доступа к ftp и xml-rpc
6) классы для отправления email, работы с сессиями, работы с календарем
7) класс-листалка, класс-простенький манипулятор над изображениями
Возможно пункты из второго списка себя не оправдают, так как в интернете достаточно много других классов, написанных с теми же целями, которые вероятно покажут себя лучше.
С хелперами для построения форм или таблиц я вообще не собираюсь связываться — это точно здец, плюс у меня объекты будут сами мапиться в формы и обратно.
Класс валидации форм оказался для меня очень простеньким, буду делать свою реализацию.
Кеширование в CI немного не такое, какое мне нужно, тоже будем писать своё.
Чего мне не хватало и я написал это сам:
1) реализация паттернов Registry и IdentityMap
2) мне нужны data-mapper`ы, как раз над ними работаю
Врезать в CI свою функцию __autoload() не составило никакого труда, так же как и пользоваться своими классами, сложенными в отдельную папочку рядом с CI. Писать свои классы как CI-библиотеки или плагины нет никакого желания, пусть они будут от него независимыми.
Итог:
1) CI дал мне несколько удобных вещей, которые мне пришлось бы реализовывать самостоятельно. Вещи эти достаточно базовые и пере-затачивание их от проекта к проекту не требуется
2) необходимые вещи я спокойно добавил в CI, трудностей не возникло
3) в CI есть вещи, которые мне не нужны или не устраивают меня, или даже бесят, но они лежат себе в файликах и меня не колышат.
Вывод:
CI вам предоставляет свой инструментарий но не ограничивает вас в его расширении сторонними разработками. Пользуйтесь ровно тем, что вам надо, на остальное забейте.
---
Сорри, если сумбурно изложил мысль => ночь+усталость
Вы пробовали выключить и снова включить?