Не. Принципиальное отличие. Stackedit это сервис. У меня библитека-фреймворк. Stackedit редактирует только Markdown, на моей библиотеке можно строить веб-сайты и веб-приложения. У меня предусмотрена возможность создавать сложные составные документы с интерактивными элементами. Stackedit позволяет загружать скрипты. В Markdown webdocs технология для создания подгружаемых веб-компонент. Интеграция с GitHub удобнее, чем возможность экспорта у Stackedit. Markdown webdocs можно использовать как подчиненную библитеку, импортируя документ в другую CMS (правда я еще не интегрировал не с одной, в планах).
Ну то есть отличие сервис редактирования <-> библиотека.
Ну и различия в состоянии проекта. Стэкедиту почти год, он отдизайнерен и проработан, тяжелый как носорог, мегабайта полтора-два уже наверное весит на страничке.
Мы уходим от моего исходного тезиса. Надеюсь вы на досуге подумаете над моими вопросами почему у вас при росте количества инвариантов не растет сложность тестирования и поймете наконец, что TDD процесс не полный. И всё сложится «само собой» это как-то очень уж легкомысленно звучит в виду этого.
Отказ от защиты данных в большинстве случаев все-таки приводит к уменьшению количества багов, не всё мы пишем публичное API и не работаем в команде мартышек или вредителей, а совокупное уменьшение сложности и дает в конечном итоге уменьшение бажности.
Что я слышу что вы используете TDD и у вас не происходит роста сложности тестирования при росте количества инвариантов, может быть это вы чего-то не понимаете в TDD? Количество инвариантов растет, количество тестов не увеличивается, вам это совсем-совсем не кажется подозрительным? Вы ничего не замечаете?
И вообще, что это за намеки про удар палкой по голове, риталин? Вам сколько лет вообще? При встрече в реале думаю такие фантазии у вас прекратились бы мгновенно.
Я ответил на оба ваших абзаца, читать нужно. Вы написали поддерживать проще, я вам ответил — инварианты порождают кратный оверхед, а это поддерживать совсем не просто и экспоненциальный рост сложности тестирования.
У автора нет логических обоснований выбранной стратегии, а у меня есть серъезные примеры и причины сильно сомневаться в этой стратегии. А где ваши «вполне конкретные хорошие реализации»?
У меня четкое мнение по этому вопросу и я могу аргументировать свою позицию. А вы мне ответили в духе авторитетствования, никаких аргументов. И после этого обозвать меня троллем, это, хм, не мудро.
О, мощный аргумент однако. Вы так говорите как будто бы это хорошо. Все чего они достигли с этим подходом, это 5-10 кратный овехед во всем, финансировании, объеме кода, а на выходе мы получаем что-нибудь вроде IE и необходимость покупать технологии и приглашать специалистов со стороны.
Я дико извиняюсь, но у этого автора ООП головного мозга в критической стадии. Абстрактные идеи безопасной модели классов для него важнее соображений легкости проектирования, надежности, читабельности и обслуживаемости кода. Вакуумный ботан копается в пестиках и тычинках. И это не то же самое что освоить базовые правила, что бы потом перейти к нужным вещам, он совершенно не пытается осознать какая цель и стратегия у программирования в целом. У него на выходе всегда абсолютно правильный и на столько же абсолютно бесполезный и ненужный ответ.
Честно говоря да, подумал что вы из тех консалтеров которые за миллионы рисуют красивые картинки, рад был ошибиться. Ну тогда прошу больше реализма, так как оно есть в реальной жизни, а не с глянцевыми картинками.
И да, все-равно заказчик должен вдохнуть жизнь в проект, иначе получается что заказчик и исполнитель перепутаны местами. Нельзя вот так просто взять и купить проект продающего интернет-магазина, можно только создать или украсть :)
Получается что в процессе, в методологии чего-то явно нехватает. Вы скажете тестирования, я скажу знаний предметной области. То есть у вас не методология проектирования, а методология подготовки проектной документации, раз результат еще нужно адаптировать под предметную область.
Хорошо, фундаментально. Но как так получается, что после такой фундаментальной подготовки, к примеру, сделан акцент на блоке «пользователи просматривающие сейчас», а «чат с менеджером» затерялся внизу?
Еще один. В большинстве конечно согласен, тем более что ничего нового они не придумали, но в топку такие туториалы, которые несовместимы с большинством IDE и добавляют нераберихи в давние войны тупоконечников и остроконечников. Это я про табы в два пробела.
Там нет точного описания признаков, того что именно происходит в системе при удалении сбойной версии, как и что удалилось, а это нужно для понимания и восстановления системы. Когда windows не запустилась, по этому тексту пользователь даже не поймет его ли это был случай. Всю информацию сейчас люди берут с технических форумов, а Яндекс трусливо спрятался за этой невнятной отпиской. Я лично воспринимаю это как пример недостойного поведения некоторых их сотрудников. И не понимаю причин такого поведения, ведь и замять им не удалось ничего, и пользователей своей программы они этой отпиской от ухода не спасут, и репутацию подмочили не меньше чем самим произошедшим сбоем.
Со стороны советовать проще, поэтому попробую: создать аварийный раздел с описанием возникшей ситуации, инструкциями в помощь для понимания и восстановления, обеспечить саппорт пострадавшим. Давать в форумах в соответствующих темах ссылки на этот раздел, дать возможность находить через поисковик по соответствующим ключевикам, а не пытаться замять. Извинения может кому-то и нужны, но пользы от них нет, поэтому смысла в них не вижу.
Вот такую реакцию лично я бы воспринял нормально. Сужу по себе, я достаточно позитивно воспринимаю сервисы Яндекса и стараюсь ими пользоваться, просто потому что я неоднократно обращался в их саппорт и за исключением первого случая получал адекватную помощь. Минимизировать последствия это важно.
У вас последние две строки неэквивалентны, в третей три приведения i к строке, в четвертой одно.
Строки в современных браузерах оптимизированы для модификации, то есть + не вызывает перевыделение памяти каждый раз и давние рекомендации join сейчас уже неактуальны. А в общем пишите как вам удобнее, эти микросекунды сейчас редко где важны.
* Я вот чего-то не понимаю. Это же вроде бы уязвимость. То есть Яндекс по хорошему должен прислушиваться к таким сообщениям, а то и материально вознагрждать за обнаружение. Но вот сколько я не писал об этом, обнаруживается тотальное непонимание, неприятие. Им там безопасность не нужна?
Эти права конечно можно и назначать, но кто этим будет заниматься, если «проблемы нет»? Так же и в яндексе скорее всего посчитали «проблемы нет, можно назначить права» и просто выкинули это замечание. А проблема на самом деле есть и очень активно эксплуатируется зловредами, спросите наверное любого антивирусника сколько процентов зловредов пишут вредоносный код в темп-каталог. Я не специалист по безопасности но и у меня было два заражения через темп-каталог просто когда я серфил по сети, это видимо были те дыры в java которые потом закрыли.
Проблема не в самих гномиках, проблема в культивируемой с помощью этих гномиков элитарности. Ошибаемся мы все независимо от уровня наших способностей, но культивируемая элитность дает конечно плюс в мотивацию, но и большой минус в способности воспринимать и обрабатывать фидбек, критику, замечания.
Доступ на запись в этот каталог и к файлам апдейта имеют другие процессы, а запуск осуществляется с повышенными привилегиями запрос на которые идет от доверенного процесса. И темп-каталог может быть общим для разных пользователей. Лишняя дыра в безопасности.
Ну то есть отличие сервис редактирования <-> библиотека.
Ну и различия в состоянии проекта. Стэкедиту почти год, он отдизайнерен и проработан, тяжелый как носорог, мегабайта полтора-два уже наверное весит на страничке.
Отказ от защиты данных в большинстве случаев все-таки приводит к уменьшению количества багов, не всё мы пишем публичное API и не работаем в команде мартышек или вредителей, а совокупное уменьшение сложности и дает в конечном итоге уменьшение бажности.
И вообще, что это за намеки про удар палкой по голове, риталин? Вам сколько лет вообще? При встрече в реале думаю такие фантазии у вас прекратились бы мгновенно.
У автора нет логических обоснований выбранной стратегии, а у меня есть серъезные примеры и причины сильно сомневаться в этой стратегии. А где ваши «вполне конкретные хорошие реализации»?
О, мощный аргумент однако. Вы так говорите как будто бы это хорошо. Все чего они достигли с этим подходом, это 5-10 кратный овехед во всем, финансировании, объеме кода, а на выходе мы получаем что-нибудь вроде IE и необходимость покупать технологии и приглашать специалистов со стороны.
Что-то эпик-фейлы зачастили, не к добру это.
Честно говоря да, подумал что вы из тех консалтеров которые за миллионы рисуют красивые картинки, рад был ошибиться. Ну тогда прошу больше реализма, так как оно есть в реальной жизни, а не с глянцевыми картинками.
И да, все-равно заказчик должен вдохнуть жизнь в проект, иначе получается что заказчик и исполнитель перепутаны местами. Нельзя вот так просто взять и купить проект продающего интернет-магазина, можно только создать или украсть :)
Вот такую реакцию лично я бы воспринял нормально. Сужу по себе, я достаточно позитивно воспринимаю сервисы Яндекса и стараюсь ими пользоваться, просто потому что я неоднократно обращался в их саппорт и за исключением первого случая получал адекватную помощь. Минимизировать последствия это важно.
Строки в современных браузерах оптимизированы для модификации, то есть + не вызывает перевыделение памяти каждый раз и давние рекомендации join сейчас уже неактуальны. А в общем пишите как вам удобнее, эти микросекунды сейчас редко где важны.