Методика простая – используйте grunt, там есть все необходимые инструменты.
Можете что-нибудь предложить в качестве решения задачи онлайн редактирования большого (страниц 10-15) отформатированного текста на основе тэгов?
Конкретных идей у меня нет (не размышлял на эту тему), но предложенный вариант и вообще ход мыслей, основанный на том, что обязательно должны быть режимы представления и кода – не нравится. Если честно, не до конца понял, чем вам ворд для больших документов не подошел. Я в режиме структуры без проблем делал 150-страничный дисер. Поясните пожалуйста подробнее, в чем у вас возникла сложность с вордом?
Есть соображения, что должен быть хороший инструмент распознавания ввода, возможно общепринятая простая нотация для этого ввода. В случае, если режимы кода/отображения исключительно необходимы, то надо делать что-то безрежимное, как пример latex, или тот-же annotated source в backbone/underscore, где видно сразу обе части и происходит синхронное выделение фрагментов.
Мне просто не понравилось решение. С т. з. юзабилити, довольно неудобно выделять код, нажимать редактировать, потом сохранять. Во-первых, это слишком много действий, во-вторых это создает лишний режим.
Сама предпосылка вида
представление отделено от кода
вызывает вопрос. Зачем вам код? Вы заметку пишете или код?
Прежде чем бросаться с места в обрыв, я бы сидел и думал над сценариями и вариантами реализации, чтобы быть совершенно уверенным в решении.
Поэтому я просто поделился с вами абсолютно верными методиками гарантии качества продукта.
И кстати, вы очень многословны для такой мелочи – ощущение, что текста написали больше, чем кода. Надо понимать, что будет людям интересно читать.
Долгосрочная цель – это сохранение генофонда, и она давно уже эффективно решается с древних времен.
Остальное, чем бы вы не занимались – лишь реализация вашей внутренней энергии.
Понятнее что – направление угла? А обычная геометрия вся такая непонятная?
И то, что теперь синусы и косинусы углов известных векторов будут давать совершенно иные результаты, чем в математике – незначительный побочный эффект?
Не думаю, что это хоть сколько-нибудь весомое обоснование: это бы скорее было тогда каким-то гуманитарно-ассоциативным видением стандартов. Если это решение было принято только из соображения «обход оступов», «направление часов», «навигация и картография», и человек эту ассоциативную связь оценивает больше, чем совместимость со всеми существующими ныне реализациями и с геометрией – это скопрометирует доверие к стандарту и разочарует любого здравомыслящего разработчика. Благо, разработчики броузеров пока не собираются реализовывать эту ересь.
Насчет градиентов – с ума посходили‽ С какой целью так меняют нотацию – непонятно. С чего вдруг, казалось, еще со школьной геометрии угол 0° вдруг становится на севере, с направлением по часовой, и с теперь неинтуитивной тригонометрией? С чего вдруг естественным направлениям прибавилось to? Зачем?
Поставил бы большой дизлайк автору этих идей!
К тому же выводу пришел, изучив вики node-webkit.
Еще бы всяческие обертки системных API имелись, так цены бы им не было. Пока что для таких вещей, как, к примеру, системные хуки, придется писать модуль на C++, а node-ffi не вариант для конечного пользователя.
высота потолков жилых помещений рассчитывалась исходя из пропорций человека
Вот-вот, это уже похоже на рационализацию. Так же и ширина колонок должна рассчитываться — исходя из контента, а не из любви к пропорциям. Представьте, если бы архитектор любил круглые числа и все потолки делал по 2м, или делил ширину дома на 12, получая размер квартиры.
величины берутся не из воздуха … хочется в это верить.
Вот именно. Надо просто доверять другим людям в смежных профессиях, а не тратить их время наивными вопросами.
Отлично, что вы не против побеседовать с дизайнером, только остается вопрос, насколько это эффективное для дела времяпрепровождение? Если вам и дизайнеру оплачивают часы дискуссий и образования на тему дизайна и метафизики — здорово, я мечтаю о такой работе. Обычно же образование дизайнера о принципах работы хэша и образование программистов о канонах типографики не несет эффекта для проекта, скорее наоборот — порождает лишние вопросы, споры и заморочки.
И еще — почему дизайнер должен вам это все объяснять? Вы же не станете объяснять дизайнеру принципы работы хэша или алгоритмы поиска на сложных структурах‽
Повторю. Если вы перестанете думать о цифрах, а сосредоточитесь на результате, то обнаружите, что качественный результат делается и безотносительно всяких закономерностей. Ваша сетка — не панацея. Молиться на неё и втискивать очевидно неподходящие объекты в неё — тратить попусту свое время. У сетки должно быть весомое обоснование для применения, к примеру, фирменный стиль, или сквозное согласование дизайна на страницах/сайтах. А если вам нужна просто колонка слева — то совершенно необязательно для этого выдумывать сетку — нарисуйте колонку размера, при котором тексту в ней не тесно, и даже не вспоминайте о цифрах.
Ширина колонки не может быть просто 300px, это либо 1/3 от всей ширины сайта, либо 4/12 от 12 колоночной раскладки, либо 1/2 от 2/3 по ширине колонки. Здесь нет никакой магии — только рациональная реализация.
OMG, и вы еще говорите о рациональности, даже не поинтересовавшись назначением колонки и характером контента в ней, а сразу выдав пропорции. Ширина колонки может быть совершенно любой. То, что вы заморачиваетесь над её пропорцией — говорит о вашей вере в тайный смысл пропорций, под предлогом псевдорационализации. Здесь могут быть только два рациональных обоснования — либо уже утвержденная сетка (читай применение фреймворка, к примеру всем известного), либо характер контента внутри колонки, но никак не любовь к круглым числам и рациональным пропорциям. Вопрос о ширине колонки не может быть обоснованием для создания самой сетки. Легче вам делать в пропорции — делайте, но когда это очевидно портит визуальную сторону — а это случается часто, т. к. вы искусственно ограничиваете себя и втискиваете содержание в какие-то априорные формы — не надо врать, что это рационализация, это будет как раз наоборот.
Про архитекторов аналогия не верная. Правильнее сравнивать дизайнера с декораторами интерьеров/экстерьеров. С архитекторами тогда уж надо сравнивать информационных архитекторов — их ответственность такая же.
И каким именно образом должен включиться мозг, чтобы объяснять те или иные размеры рационально? А радиусы скругления углов кнопок вам тоже объяснять? Кривизну овалов в логотипе? Может вам в формулах кривых логотипа найти логику и закономерность? А выбор цветов в градиенте на кнопке объяснить? Или может выбранный трекинг шрифта вам пояснить? А на вопрос почему интерлиньяж 16px вместо 15px вам также надо рациональное объяснение найти? Высоту и ширину полей вам надо сеткой аргументировать? Вам во всех этих вопросах надо придумать скрытые смыслы/аргументы/дать ссылки на исследования?
То, что вы считаете, что 300px априори лучше, чем, к примеру, 345.23866666666px, говорит лишь о вашей странной любви к магическим круглым числам, будто если все сделаешь по ним — получится хорошо; для вас удобство реализации важнее результата, а это заблуждение, которое на самом деле только замедляет процесс реализации.
Если бы вы вообще не думали о цифрах, а ориентировались только на визуальную сторону, то обнаружили бы с удивлением, что сильные и качественные работы не поддаются очевидным законам «округленных» чисел и чистых пропорций.
Методика простая – используйте grunt, там есть все необходимые инструменты.
Конкретных идей у меня нет (не размышлял на эту тему), но предложенный вариант и вообще ход мыслей, основанный на том, что обязательно должны быть режимы представления и кода – не нравится. Если честно, не до конца понял, чем вам ворд для больших документов не подошел. Я в режиме структуры без проблем делал 150-страничный дисер. Поясните пожалуйста подробнее, в чем у вас возникла сложность с вордом?
Есть соображения, что должен быть хороший инструмент распознавания ввода, возможно общепринятая простая нотация для этого ввода. В случае, если режимы кода/отображения исключительно необходимы, то надо делать что-то безрежимное, как пример latex, или тот-же annotated source в backbone/underscore, где видно сразу обе части и происходит синхронное выделение фрагментов.
Сама предпосылка вида
вызывает вопрос. Зачем вам код? Вы заметку пишете или код?
Прежде чем бросаться с места в обрыв, я бы сидел и думал над сценариями и вариантами реализации, чтобы быть совершенно уверенным в решении.
Поэтому я просто поделился с вами абсолютно верными методиками гарантии качества продукта.
И кстати, вы очень многословны для такой мелочи – ощущение, что текста написали больше, чем кода. Надо понимать, что будет людям интересно читать.
Остальное, чем бы вы не занимались – лишь реализация вашей внутренней энергии.
И то, что теперь синусы и косинусы углов известных векторов будут давать совершенно иные результаты, чем в математике – незначительный побочный эффект?
Поставил бы большой дизлайк автору этих идей!
Еще бы всяческие обертки системных API имелись, так цены бы им не было. Пока что для таких вещей, как, к примеру, системные хуки, придется писать модуль на C++, а node-ffi не вариант для конечного пользователя.
И сайт еще у них есть: appjs.org
Вот-вот, это уже похоже на рационализацию. Так же и ширина колонок должна рассчитываться — исходя из контента, а не из любви к пропорциям. Представьте, если бы архитектор любил круглые числа и все потолки делал по 2м, или делил ширину дома на 12, получая размер квартиры.
Вот именно. Надо просто доверять другим людям в смежных профессиях, а не тратить их время наивными вопросами.
OMG, и вы еще говорите о рациональности, даже не поинтересовавшись назначением колонки и характером контента в ней, а сразу выдав пропорции. Ширина колонки может быть совершенно любой. То, что вы заморачиваетесь над её пропорцией — говорит о вашей вере в тайный смысл пропорций, под предлогом псевдорационализации. Здесь могут быть только два рациональных обоснования — либо уже утвержденная сетка (читай применение фреймворка, к примеру всем известного), либо характер контента внутри колонки, но никак не любовь к круглым числам и рациональным пропорциям. Вопрос о ширине колонки не может быть обоснованием для создания самой сетки. Легче вам делать в пропорции — делайте, но когда это очевидно портит визуальную сторону — а это случается часто, т. к. вы искусственно ограничиваете себя и втискиваете содержание в какие-то априорные формы — не надо врать, что это рационализация, это будет как раз наоборот.
Про архитекторов аналогия не верная. Правильнее сравнивать дизайнера с декораторами интерьеров/экстерьеров. С архитекторами тогда уж надо сравнивать информационных архитекторов — их ответственность такая же.
То, что вы считаете, что 300px априори лучше, чем, к примеру, 345.23866666666px, говорит лишь о вашей странной любви к магическим круглым числам, будто если все сделаешь по ним — получится хорошо; для вас удобство реализации важнее результата, а это заблуждение, которое на самом деле только замедляет процесс реализации.
Если бы вы вообще не думали о цифрах, а ориентировались только на визуальную сторону, то обнаружили бы с удивлением, что сильные и качественные работы не поддаются очевидным законам «округленных» чисел и чистых пропорций.