Регистры в KateJS на текущий момент на самом деле довольно простые. Таблица одна. На умеренных объемах данных этого достаточно. Будут большие объемы — будет повод заняться оптимизацией.
Сложной аналитической системы тоже нет: данные агрегируются так как решит разработчик. бОльшую часть можно сделать силами СУБД. Своего языка запросов нет — используется api от sequelize или прямые SQL запросы.
Систему автоматизации завода на 10к сотрудников на KateJS я бы делать не рекомендовал. А специфический учет для ИП на УСНО — вполне.
Если я правильно понял, то аналог с кино был бы такой: расставляя кадры в обратном порядке — получилась бы другая история. Если с музыкальным произведением в посте более-менее понятно, то с кино теоретически сомнительно, что вообще можно придумать такой сценарий.
Braid очень оригинальная игрушка. Там много интересных идей с манипуляцией временем. Моя идея про другое: как пазл, в котором можно собрать две совершенно разные картины из одно набора.
Впрочем далеко в Braid не заходил, может там чего-то такое и есть.
Есть идея — сделать кино: фильм из двух частей, рассказывающий две истории, где вторая история полностью состоит из кадров первой. Начинается вторая часть, зритель видит те же виды, тех же людей, те же кусочки диалогов, что и в первой части, только расставленные в другом порядке. Получается полноценная вторая часть, но с совершенно другой историей. Думаю, помимо забавности самого факта такого фильма его будет еще и интересно смотреть (если постараться со сценарием): зритель, в процессе просмотра второй части сообразит в чем фишка и будет пытаться разгадать финал.
Кино не является моей профессией, поэтому рассматриваю эту затею как одно из хобби. Однако в одно лицо реализую я ее еще не скоро. Если кто заинтересовался и готов вложить ресурсы — давайте попробуем сделать вместе.
если вашими основными заказчиками будут бюджетные организации или крупный бизнес, то им нужен как раз ИП, работающий на ОСНО.
Чтоб поставить все на место поясню: крупному бизнесу выгодно, если вы предоставляете услуги с НДС, т.к. на сумму НДС с ваших услуг они заплатят меньше налога. Иными словами реально ваши услуги обойдутся им на 18% дешевле.
Надо включить голову. Вы то эти 18% должны будете заплатить. И если речь идет про ИТ услуги, то вам придется увеличить стоимость своих услуг на 18%, чтоб получить столько, сколько вы за них хотите.
Что получаем: вы увеличиваете стоимость услуг на 18%, чтоб крупный клиент получил льготу по налогу на эти 18%. Не проще изначально отказаться от НДС (от ОСНО) и не накручивать эти 18%?
Если вы конкурируете по цене, то для плательщика НДС будет выгодней с вами работать, если ваши цены будут более чем на 18% ниже, чем цена той компании, которая предоставляет услуги с НДС.
Есть, конечно, упертые клиенты, которые не хотят принимать аргументы, что стоимость на 20% меньше лучше чем та же стоимость, но с НДС и твердят как мантру «нам нужны поставщики с НДС, нам нужны поставщики с НДС, нам нужны поставщики с НДС»… Многого не потеряете, если такие люди не будут вашими клиентами.
Поддержу. Аналогично — мы у себя не используем промисы. И при этом никакой лапши нет. Правда спастись от нее помогла не книга, а одна простая статья «Лапша» из callback-ов — будьте проще (очередное спасибо автору).
Не хочу показаться занудным, но этот случай мне кажется нетипичным. Детальных условий задачи я, конечно, не знаю, может на самом деле была такая необходимость все это делать на клиенте силами js, не привлекая сервер.
Под нетипичные задачи всегда приходится как-нибудь да оптимизировать код.
Мне хочется понять, реально ли необходимо заморачиваться на экономию памяти в замыканиях при решении обычных задач.
Помогите, пожалуйста, разобраться.
А есть ли реальная потребность создавать такое большое количество инстансов, что это может привести к излишнему потреблению памяти? Можете привести какой-нибудь реальный пример?
Пришлось дочитать до этого комментария, чтоб понять в чем вызов :)
Могу предложить такую «идею».
Выше уже озвучивали, что знание и информация — разные вещи. Да, информация стала легкодоступной, но знание — термин несколько более широкий. Ну а ваш вызов, на мой взгляд, совсем не новый. Я приведу упрощенные примеры.
На физтехе (не знаю как сейчас, но 10 лет назад было так) на экзамен по физике разрешено приносить любую литературу в любом количестве и свободно пользоваться. Просто там задачи такие, что если студент не понимает — то учебники ему не помогут. Зубрилам там было непросто. Физиков логично проверять на понимание.
Пример про врачей, думаю, очевиден — никакой визуальный мануал не поможет сделать операцию на сердце, если человек до этого сердца не касался. У врачей логично проверять умения или навыки. Далек от медицинского образования, но, думаю, в хорошем образовательном учреждении этой тематики хорошо знают что и как проверять.
Отвечу и про историю. Как вариант — можно ее рассматривать как «чужой опыт» — множество людей в течение длительного времени совершали огромное количество ошибок. Если задача стоит в том, чтобы обучить, например, политика — ему крайне полезно будет узнать максимальное количество негативных примеров в этой области, чтобы не наступать на грабли, на которые уже наступали люди до него. Метод проверки традиционный.
Ну а вопросы на собеседованиях в ИТ области типа «а какая команда в mySQL очищает таблицу» у меня всегда вызывали сомнения в том, кто такие вопросы задает как в специалисте в области ИТ.
Проверять — не проблема. Просто в разных областях надо проверять разное.
Вот как учить…
Не смог найти в новой версии хоть какого-нибудь средства для подсчета времязатрат. В прошлой — отображалось итого часов, можно было сделать отчет. Сейчас — никак.
Совокупность правил — не всегда метод. Не буду утверждать, что ваш набор правил — это не метод. Метод. Но не для всех — высокий «порог входа». Думаю, что не более половины читателей хабра сможет с завтрашнего дня начать его использовать.
Вы привели определение, под которое статья подходит на 100%. Учитывая тон вашего комментария, могу сделать лишь один вывод — вы ее не читали. Комментарии, действительно, излишни.
p.s. Спасибо за ваш первый комментарий, он указал на неточности формулировки заголовка — я его исправил.
А вы уверены в своем понимании того, чего я бы хотел от вас услышать? Можете не отвечать — не важно.
Я тоже не люблю переходить на личности, но кому-то в комментариях уже пообещал описать свой личный пример. Постараюсь сдержать это обещание.
По поводу методики. У самого слова — «методика» — сильно размытое определение. Возможно, стоило озаглавить статью «Метод ...». Я специально оформил статью в виде рецепта — алгоритма, чтобы учесть специфику ресурса. Вся статья написана в повелительном наклонении и представляет собой четкий алгоритм достижения цели. В заголовке, я даже имел неосторожность написать про гарантии. Верить мне или нет — решать вам, но я готов подписаться за своими словами.
По поводу крайностей. Я, также как и вы и многие другие люди, потратил некоторое количество времени на поиск метода, который бы мне лучше всего подходил. Прежде чем написать эту статью, метод прошел жесткий отбор, тестирование на себе, на других и много попыток объективной оценки. Лучше — я не знаю. Да, преувеличение есть, спорить не буду. Если задел вас — извиняюсь.
Предлагая спор по эффективности, я даже и не предполагал варианта решить его на словах. Где-то ниже уже озвучивал конкретное предложение: попробуйте, сравните, опишите — оценим по результатам. Впрочем, прочитав ваши правила, думаю, что вряд-ли вы будете спорить — вам это неинтересно.
Кстати, среди моих правил, есть все 6 ваших — полностью из поддерживаю :)
Но все же, это правила. В статье я написал — метод.
Сложной аналитической системы тоже нет: данные агрегируются так как решит разработчик. бОльшую часть можно сделать силами СУБД. Своего языка запросов нет — используется api от sequelize или прямые SQL запросы.
Систему автоматизации завода на 10к сотрудников на KateJS я бы делать не рекомендовал. А специфический учет для ИП на УСНО — вполне.
Впрочем далеко в Braid не заходил, может там чего-то такое и есть.
Кино не является моей профессией, поэтому рассматриваю эту затею как одно из хобби. Однако в одно лицо реализую я ее еще не скоро. Если кто заинтересовался и готов вложить ресурсы — давайте попробуем сделать вместе.
Чтоб поставить все на место поясню: крупному бизнесу выгодно, если вы предоставляете услуги с НДС, т.к. на сумму НДС с ваших услуг они заплатят меньше налога. Иными словами реально ваши услуги обойдутся им на 18% дешевле.
Надо включить голову. Вы то эти 18% должны будете заплатить. И если речь идет про ИТ услуги, то вам придется увеличить стоимость своих услуг на 18%, чтоб получить столько, сколько вы за них хотите.
Что получаем: вы увеличиваете стоимость услуг на 18%, чтоб крупный клиент получил льготу по налогу на эти 18%. Не проще изначально отказаться от НДС (от ОСНО) и не накручивать эти 18%?
Если вы конкурируете по цене, то для плательщика НДС будет выгодней с вами работать, если ваши цены будут более чем на 18% ниже, чем цена той компании, которая предоставляет услуги с НДС.
Есть, конечно, упертые клиенты, которые не хотят принимать аргументы, что стоимость на 20% меньше лучше чем та же стоимость, но с НДС и твердят как мантру «нам нужны поставщики с НДС, нам нужны поставщики с НДС, нам нужны поставщики с НДС»… Многого не потеряете, если такие люди не будут вашими клиентами.
Спасибо за ответ.
Под нетипичные задачи всегда приходится как-нибудь да оптимизировать код.
Мне хочется понять, реально ли необходимо заморачиваться на экономию памяти в замыканиях при решении обычных задач.
А есть ли реальная потребность создавать такое большое количество инстансов, что это может привести к излишнему потреблению памяти? Можете привести какой-нибудь реальный пример?
Могу предложить такую «идею».
Выше уже озвучивали, что знание и информация — разные вещи. Да, информация стала легкодоступной, но знание — термин несколько более широкий. Ну а ваш вызов, на мой взгляд, совсем не новый. Я приведу упрощенные примеры.
На физтехе (не знаю как сейчас, но 10 лет назад было так) на экзамен по физике разрешено приносить любую литературу в любом количестве и свободно пользоваться. Просто там задачи такие, что если студент не понимает — то учебники ему не помогут. Зубрилам там было непросто. Физиков логично проверять на понимание.
Пример про врачей, думаю, очевиден — никакой визуальный мануал не поможет сделать операцию на сердце, если человек до этого сердца не касался. У врачей логично проверять умения или навыки. Далек от медицинского образования, но, думаю, в хорошем образовательном учреждении этой тематики хорошо знают что и как проверять.
Отвечу и про историю. Как вариант — можно ее рассматривать как «чужой опыт» — множество людей в течение длительного времени совершали огромное количество ошибок. Если задача стоит в том, чтобы обучить, например, политика — ему крайне полезно будет узнать максимальное количество негативных примеров в этой области, чтобы не наступать на грабли, на которые уже наступали люди до него. Метод проверки традиционный.
Ну а вопросы на собеседованиях в ИТ области типа «а какая команда в mySQL очищает таблицу» у меня всегда вызывали сомнения в том, кто такие вопросы задает как в специалисте в области ИТ.
Проверять — не проблема. Просто в разных областях надо проверять разное.
Вот как учить…
Есть статья у Джоэла Спольски на крайне похожую тему: Закон дырявых абстракций.
Переформулирую и дополню свою фразу.
Совокупность правил — не всегда метод. Не буду утверждать, что ваш набор правил — это не метод. Метод. Но не для всех — высокий «порог входа». Думаю, что не более половины читателей хабра сможет с завтрашнего дня начать его использовать.
Свой метод, я постарался сделать более доступным.
p.s. Спасибо за ваш первый комментарий, он указал на неточности формулировки заголовка — я его исправил.
Я тоже не люблю переходить на личности, но кому-то в комментариях уже пообещал описать свой личный пример. Постараюсь сдержать это обещание.
По поводу методики. У самого слова — «методика» — сильно размытое определение. Возможно, стоило озаглавить статью «Метод ...». Я специально оформил статью в виде рецепта — алгоритма, чтобы учесть специфику ресурса. Вся статья написана в повелительном наклонении и представляет собой четкий алгоритм достижения цели. В заголовке, я даже имел неосторожность написать про гарантии. Верить мне или нет — решать вам, но я готов подписаться за своими словами.
По поводу крайностей. Я, также как и вы и многие другие люди, потратил некоторое количество времени на поиск метода, который бы мне лучше всего подходил. Прежде чем написать эту статью, метод прошел жесткий отбор, тестирование на себе, на других и много попыток объективной оценки. Лучше — я не знаю. Да, преувеличение есть, спорить не буду. Если задел вас — извиняюсь.
Предлагая спор по эффективности, я даже и не предполагал варианта решить его на словах. Где-то ниже уже озвучивал конкретное предложение: попробуйте, сравните, опишите — оценим по результатам. Впрочем, прочитав ваши правила, думаю, что вряд-ли вы будете спорить — вам это неинтересно.
Кстати, среди моих правил, есть все 6 ваших — полностью из поддерживаю :)
Но все же, это правила. В статье я написал — метод.