Comments 89
Что я только что прочитал?
Если у вас вопрос «а как на dap сделать X, да так чтобы Y» или аналогичный — буду рад ответить во всех подробностях.
Как понимаю в идею вложено не мало сил и поэтому это весьма болезненно бьёт по самолюбию.
Но от плохих идей надо уметь отказываться, не терять на них своё время и силы, учитывать ошибки и делать по новому более жизнеспособное.
У вас слишком творческий™ порыв и вы заигрались в идею забыв о практичности.
Я более чем уверен через пол года посмотрив на этот код вы сами будете недоумевать от того что понаписали. Сейчас вы в «ловушке создателя», когда вам всё понятно и хорошо, но это потому что вы сами написали и всё помните, когда вы на этот код посмотрите с точки зрения человека со стороны ваши розовые очки сломаются.
Вам нужно выжать максимально идею и сделать максимально просто и удобно для людей.
Были гораздо более перпективные и дружелюбные для входа фреймворки которые не получилось продвинуть, а у вас с этим куда хуже. Сейчас вы совершаете похожую ошибку как автор фреймворка $mol.
Получение данных в UI не лучший подход.
Почему у этого лицензия не MIT, не понятно.
Заголовок кликбейтный. Думал — какой-то маленький движок как альтернатива V8. Оказалось — очередной "гениальный фреймворк".
Пойдите другим путём — сделайте отдельный язык, компилируемый в JS. Тогда всё встанет на свои места. Всё это безумие решёток, вопросительных знаков, кавычек и скобочек обретёт смысл, плюс вам не придётся выслушавать от JS-еров вопли «мои глаза». Потому что это будет уже не JS.
Ну и фраза «Никаких npm install и вот этого всего» это минус, а не плюс. В современной веб-разработке под браузер всё идёт через npm и если вашу либу нельзя проинсталить и скормить в babel/webpack, то никто ею и пользоваться не будет.
Так он же уже есть язык этот. Брэйнфак называется.
А вот dap как раз обходится средствами голого JS. И почему вы думаете, что выслушивать вопли «JS-еров»-неофитов — это что-то плохое? :)
Непонятно, что вы называете безумием решеток и кавычек. Обилие решеток здесь — это «безумие» CSS-файла, который писал не я, и который к dap отношения не имеет. Кавычки и скобочки вас пугают? А вы когда на JS/HTML последний раз писали? Сравните, пожалуйста, на количество кавычек и скобочек (и их видов) вот эти два выражения:
'#toggle-all type=checkbox'
<div id="toggle-all" type=checkbox>
Мою либу вы можете проинсталить, просто взяв файл dap.js.org/0.4.js если хотите.
Другое дело, что это именно «не нужно», в смысле «не требуется».
"$completed=#.checked; (@method`PATCH .url:dehttp headers (.completed:?)):query"А, так это CSS. Похоже я сильно отстал от него )))
d("#.checked=.completed") // # обозначает "этот элемент"
Похоже, вы не от CSS сильно отстали :)
// Оператор * выполняет повтор для всех элементов массива
// # обозначает "этот элемент"
// Оператор ! просто добавляет текст в элемент
"? $editing:!; ! .title"
...
"? $editing; !! .title@value"
...
".title=#.value; (@method`PATCH .url:dehttp (@Content-type`application/json)@headers (.title):json.encode@body):query"
Очевидно же, что если я хочу писать на dap, JS мне не помощник. Нужно учить особый синтаксис. Так зачем тогда вообще нужен JS, если вся мякотка dap'а — в этих?!!! ` @
Избавьтесь от балласта, запилите свой компилятор. Elm, PureScript, ClojureScript, CoffeeScript все пошли этим путём и выйграли.
Мякотка dap вовсе не в этих *?!
я мог бы их назвать for-each, if, print. Просто зачем? Я вот сейчас реально перечислил все три(!) основных оператора, которые вам нужно «выучить», чтобы начать писать на dap. Выучить три оператора — это сложно, я понимаю, но мы не на ЕГЭ, тут дело добровольное. А, собственно, мякотка dap в том, что он позволяет просто и коротко описывать то, что средствами JS пишется громоздко, муторно и просто некрасиво. При этом dap не пытается лезть туда, где все можно просто и красиво сделать на JS. Дождитесь второй части туториала.
Зачем нужен JS — кстати это хороший вопрос, я вам с удовольствием отвечу. Изначально (2008-м году, bankreports.dapmx.org) дап строился на HTML/XML. Правила писались в атрибутах d, u и т.п. В принципе это было вполне удобно (в отличие от js-строк, SGML-атрибуты могут быть многострочными, этого сейчас иногда не хватает) и выглядело в те времена доминирования XML вполне логично (хотя синтаксис самих dap-правил был действительно адский). Но в какой-то момент я подумал: а нахрена? Зачем писать это тегами, потом парсить это все, собирать в объекты, иметь вот этот весь головняк, если все это можно прекрасно сделать средствами самого JS? Так же как сейчас я не понимаю этого прикола JSX писать в JS-коде HTML-теги.
Поэтому сейчас dap строится средствами JS, и манипулировать dap-шаблонами можно любыми доступными в JS средствами — это обычные JS объекты из обычных JS-объектов. Смысла городить отдельный язык с компилятором и монадами я просто не вижу.
В отличие от помянутых PureScript, ClojureScript, CoffeeScript, которые «вместо» JS, dap не вместо.
Слоган/девиз фреймворка: HAPPY DEBUGGING MOTHERFUCKER!!!!!
ru.vuejs.org/v2/guide/render-function.html
Уверенности в себе вам не занимать. )
Просто аналогичные игры в ассоциации уже были в комментах к предыдущей статье. Кто какой js раньше видел, тому то и мерещится. Я думаю, это нормально.
Да, строки текста на другом языке это и есть дап. С помощью js под капотом эти строки компилируются в шаблоны и реактивные связи между ними. Но js тут не только под капотом. Эти dap правила сами оперируют js-данными и js-функциями. Во второй части туториала это будет подробно. Пока можно посмотреть примеры на dap.js.org если интересно
А зачем в принципе нужен ваш фреймворк? В смысле какие задачи он решает прям на порядки лучше других? В прошлой статье вы написали:
dap — интересный и необычный язык реактивных правил для написания, в частности, веб-фронтендов
Круто, еще один DSL поможет людям, только вот с какими задачами?
В этой статье вы нарисовали пример, это здорово, но вот с мотивацией опять же все очень не ясно.
Вы, кстати, вторую часть читали уже?
Мотивация — писать чище, проще, лаконичней и декларативней, без бойлерплейта и ритуалов.
Я вот прям сейчас смотрю на ваши примеры. Чище и проще — это не про них. Если подытожить: ваша мотивация — писать мало и декларативно.
За всю свою карьеру я не встречал проектов, в которых объем кода являлся проблемой. Скорее даже наоборот, иногда нужно написать больше, что бы код был поддерживаемым, тестируемым, расширяемым и производительным. Можете привести пример проекта, где критичен именно объем кода?
Что касается декларативности — это сама цель, или способ уменьшения объема кода?
Я вот прям сейчас смотрю на ваши примеры. Чище и проще — это не про них. Если подытожить: ваша мотивация — писать мало и декларативно.
Ваша (и не только) оценка — из серии: «Я вот прямо сейчас смотрю инструкцию на китайском. Вообще ничего не понимаю. Ели подытожить: мотивация китайцев — писать по-нерусски, и не буквами».
Если у вас есть какие-то конкретные вопросы по поводу:
что бы код был поддерживаемым, тестируемым, расширяемым и производительным
— сформулируйте, я постараюсь ответить. Возможно, отдельной статьей. Но уж точно, «нужно написать больше» — это не единственный способ :)
Декларативность — это способ писать и чище, и проще, и меньше. Я уже это где-то говорил? А, и корректней.
сформулируйте, я постараюсь ответить. Возможно, отдельной статьей.
Чище/проще — это про SOLID, и в принципе направления по разделению кода. У вас же сплошной комок. В php например так не пишут уже лет 10.
Декларативность — это способ писать и чище, и проще, и меньше.
С чего вы взяли?
В php например так не пишут уже лет 10
Я бы постеснялся приводить php в пример того, «как пишут» что бы то ни было.
Комок — в вашем восприятии, а не у меня в коде. Если вам нравится писать часть логики в одном месте, часть в другом, а потом соединять это системой веревочек — ваше право.
Не относящиеся к логике конкретного приложения вещи — они и в dap отдельно пишутся. Это библиотечные элементы, алгоритмы и модели (.DICT, .FUNC и .USES как раз нужны для подключения внешних модулей) и визуал (это CSS, он и так отдельно). Но структура UI и его логика — в dap это жестко взаимосвязанные вещи, да — это накладывает некоторые ограничения, зато заставляет тщательней относиться к проектированию и писать более корректные приложения.
С чего вы взяли?
Вы спросили — для чего в dap декларативность. Я вам ответил.
Я бы постеснялся приводить php в пример того, «как пишут» что бы то ни было.
Вы явно не в теме))
Комок — в вашем восприятии, а не у меня в коде.
Помесь css, псевдо-html, js и вашего dsl — это и есть комок.
Если вам нравится писать часть логики в одном месте, часть в другом, а потом соединять это системой веревочек — ваше право.
Вы когда нибудь слышали про SOLID?
Но структура UI и его логика — в dap это жестко взаимосвязанные вещи
Именно по этой причине у вас и получается комок. Посмотрите QML на досуге, парни из Qt как раз решили эту проблему.
зато заставляет тщательней относиться к проектированию и писать более корректные приложения.
Ваш dsl усложняет проектирование архитектуры приложения.
Вы спросили — для чего в dap декларативность. Я вам ответил.
Контекст вопроса был, почему вы считаете, что декларативность это способ писать чище, проще и меньше?
почему вы считаете, что декларативность это способ писать чище, проще и меньше?
Потому что 15 кБ это меньше чем 300 кБ. Или вы не про цифры, а так… в общефилософском смысле?
Ваш dsl усложняет проектирование архитектуры приложения.
Сколько приложений на dap вы уже написали, чтобы так авторитетно об этом заявлять?
[печальный вздох и фейспалм]
Я новичок на Хабре. Здесь что, автор фактом написания статьи уже чем-то всем обязан? Вам не нравится dap, а нравится php — ок, я без проблем. Первый мой коммент к этой статье (заминусованный гордыми экспертами) полностью отражает мое отношение к этому вопросу.
Сколько приложений на dap вы уже написали, чтобы так авторитетно об этом заявлять?
На вашем детище нисколько, и никогда не напишу. Я спросил вас, какую проблему решает ваш проект. Если убрать субъективщину — это уменьшение объема кода.
Уменьшение объема кода с помощью магии и dsl чаще всего приводит к серьезному удорожанию поддержки, расширения, тестирования. В редких случаях — к упрощению чтения.
Чем больше проект — тем серьезней последствия. Для бложика, или todo листа ваш проект возможно и может экономить время, но для среднего и крупного он его будет наоборот отнимать.
Здесь что, автор фактом написания статьи уже чем-то всем обязан?
Когда вы публикуете что-то новое — будьте готовы к критике, это не только на хабре происходит. Если вы не можете качественно аргументировать те, или иные решения — это печально, особенно в публичном пространстве, типа хабра.
Вам не нравится dap, а нравится php — ок, я без проблем.
php я привел по той причине, что аналогичная проблема существовала довольно длительный период, сообщество ее осознало и решило много лет назад. Ваш dap же эту проблему создает заново.
Первый мой коммент к этой статье (заминусованный гордыми экспертами) полностью отражает мое отношение к этому вопросу.
Тогда зачем вы тратили свое время на написание статьи?))
Когда вы публикуете что-то новое — будьте готовы к критике
Я готов к критике. Но я, признаться, рассчитывал все же на уровень повыше, чем «ниасилил, но осуждаю».
зачем вы тратили свое время на написание статьи?
Вот, кстати, времени, потраченного на написание статей — вообще не жалко. Очень полезное занятие, рекомендую. Когда приходится формулировать и обосновывать, вскрываются многие интересные моменты. Дойдет ли это до скучающего критика — вообще десятый вопрос.
Но я, признаться, рассчитывал все же на уровень повыше, чем «ниасилил, но осуждаю».
Интересно, сколько лет вы работаете инженером?
Понимаете какая штука, концентрация на проблеме и ее решение в ваших статьях и комментариях очень похоже на аргументацию и уверенность новичка. В стиле "писать мало — это круто, если не согласен — докажи мне обратное".
Для новичков так же очень свойственно создавать свои правильные и самые лучшие решения. Специалисты уровня синьор и выше, как правило сразу знают множество решений одной и той же проблемы, а выбор строят на более весомых критериях, чем объем кода, как правило это: поддерживаемость, производительность, легкость интеграции, легкость расширения, тестируемость, дороговизна для бизнеса и т.д.
Решения, используемые в вашем проекте во многом противоречат общим подходам, к которым область шла годами. Именно по этой причине вам требуется очень качественная аргументация по ним.
Если аргументация не достаточно качественная — вы получаете вбросы в комментариях.
Где вы увидели в моих постах про «самые правильные и самые лучшие решения»?
Вы воспринимаете все фразы буквально? И даже кавычки вас не смутили?))
Доказывать тут что-то вдруг требуют все, кроме меня.
Если вы пиарите что-то новое, еще раз, у вас должна быть мощная аргументация о том, что вы пиарите. Хабр это не рен.тв, где бабки заряжают воду от dvd дисков, тут не надо верить. Тут вполне мощное сообщество с довольно высокой экспертизой.
Скептицизм — это отличное качество этого сообщества. Если вы хотите, что бы ваш проект восприняли серьезно — потребуется серьезная аргументация, которая переборет этот скептицизм.
И при этом считают своим долгом меня жизни поучить.
Фитбэк — он такой. Иногда жестковытый, но чаще всего по делу. Вот пример:
Слоган/девиз фреймворка: HAPPY DEBUGGING MOTHERFUCKER!!!!!
Как у вас с дебагом дела?
Как у вас с дебагом дела?
Лично у меня с дебагом dap-кода дела гораздо лучше, чем у меня же с дебагом JS-кода. Хотя, исходя из комментов тут, возможно, займусь этим поплотней. Сейчас просто ошибки в консоли пишет. Можете зайти на dap.js.org/docs поиграться с кодом и посмотреть на ошибки.
Если вы пиарите что-то новое, еще раз, у вас должна быть мощная аргументация о том, что вы пиарите.Эм… пиарю?
Сейчас просто ошибки в консоли пишет.
дебаг — это про брейкпоинты.
Эм… пиарю?
Разве нет?
Брейкпоинты в самих правилах обычно не нужны, т.к. там все просто. Но когда надо, я просто ставлю любому аргументу конвертор x=>x и на нем уже js-брейкпоинт. Оттуда все видно.
Брейкпоинты в самих правилах обычно не нужны, т.к. там все просто.
"$completed=.completed $editing=; a!"Я бы не сказал, что подобные текстовки прям простые. Один символ не на своем месте и поиск ошибки будет очень радостным.
Кстати, странно, что вы именно эту строчку выцепили. Это ж почти php. Только вместо null «ничто»
Верьте мне.
С чего вдруг?
С этим синтаксисом никогда проблем не возникает.
Ого, сильное утверждение. Правда ложное, вы следующим предложением его же опровергаете.
А если возникает, то получаете ошибку компиляции в консоли.
А что если ошибка не синтаксическая?
Это ж почти php. Только вместо null «ничто»
На php совсем не похоже. bash кстати тоже использует $ для переменных, но, на него тоже не похоже.
А что если ошибка не синтаксическая?
А где я написал, что ловятся только синтаксические? Если ошибка есть — вы о ней узнаете из консоли.
С чего вдруг?
А что вам остается? Проверять же не будете. Так что либо верить более опытному товарищу, либо продолжать фантазировать.
А что вам остается? Проверять же не будете.
С apk проверил, в отличии от вас (в начале).
Так что либо верить более опытному товарищу, либо продолжать фантазировать.
Более опытный — это только ваши слова. Зачем мне им верить? Я использую вполне научный подход. Выдвигаю гипотезу, дальше подтверждаю ее, или опровергаю. Если сталкиваюсь с похожей ситуацией — использую полученный опыт.
Вот пример: есть гипотеза, что код на dap тяжело дебажить потому, что добрая часть логики является строкой.
Подтверждение 1.
Интерпретатор js не может связать ваш исходный код на строках с тем, что будет реально выполнено. Брейпоинт ставить в строках нет смысла. Будь это по другому, вы бы указали на использование Source Maps.
Подтверждение 2.
Не синтаксические ошибки тяжело найти. Это может быть банальная очепятка, корректная с точки зрения синтаксиса. Например для логического выражения забыл добавить логическое НЕТ, или еще что-то подобное. Что мне покажет консоль? Код работает штатно, но не корректно. В других языках такие ошибки тоже бывает трудно найти. Дебаггер в этом очень помогает, но опять же, у вас он не применим.
Подтверждение 3.
Для поиска ошибок часто используется unit тестирование. Штуки типа SOLID очень помогают в этом. У вас же сплошная простыня. Простыню покрывать тестами тяжелее, чем много отдельных компонентов.
1. Как пошагово дебажить дап-код и ставить брейкпоинты? [знак вопроса]
2. Как ловить ошибки (синтаксические и несинтаксические)? [знак вопроса]
3. Как разбивать дап-программу на модули, которые можно писать, поддерживать и использовать независимо? [знак вопроса]
— то я, пожалуй, признаю этот ваш комментарий самым полезным и конструктивным из имеющихся. Хорошие темы для следующих статей. Подписывайтесь, чтобы не пропустить :)
За всю свою карьеру я не встречал проектов, в которых объем кода являлся проблемой.
Мне, например, пришлось поменять несколько телефонов тупо потому, что в 4Гб памяти не помещались одновременно Facebook, WhatsApp, PayPal, Мегафон, Сбербанк и Точка. В игры на телефоне я не играю. Только на телефоне с 128ГБ я могу (пока) расслабится. У вас это не вызывает когнитивного диссонанса? 4ГБ мало для десятка туповатых текстовых приложений.
Подозреваю, это как раз благодаря разработчикам, для которых «объем кода не являлся проблемой»
Вы понимаете, что пишете глупость?)) Объем занимаемой памяти на прямую зависит от количества создаваемых объектов и их взаимосвязей, а не от объема кода.
Следующий пример отжирает свыше 400мб, хотя это мелкий однострочник.
const arr = new Array(10000000).fill(0).map(() => (Math.floor(10 * Math.random())) + "SOME_DATA_HERE");Слив засчитан
Это Android приложение. Основную часть архива занимают скомпилированные *.so библиотеки, ассеты, ресурсы и dex файлы. Библиотеки, типа libcom.yandex.mapkit.so могут быть подключены, но это вовсе не значит, что вся функциональность из них используется, так же не значит, что все возможные объекты из каждой из библиотек создаются сразу. Так же не значит, что все ассеты подключаются и рендерятся сразу.
А слив засчитан потому, что вы понятия не имеете о чем говорите.
Это Android приложение
А, ну тогда другое дело, да.
*.so библиотеки, ассеты, ресурсы и dex файлы
Похоже, вы тоже не сильно в теме. В андроиде уже давно далвика нет, соответственно и dex-файлов, наверно, тоже. Но это не точно.
Так объем кода (в т.ч. библиотечного) имеет значение или нет?
Вы можете засчитывать что угодно, но если вместо положенных 75кБ приложение весит 75 МБ — не надо мне рассказывать, что это так и должно быть, ибо SOLID, и все так пишут, даже на пхп.
Похоже, вы тоже не сильно в теме. В андроиде уже давно далвика нет, соответственно и dex-файлов, наверно, тоже.
Вы разархивируйте apk файл для начала, а дальше рассказывайте про свои влажные фантазии о том, что там есть и чего там нет.
Так объем кода (в т.ч. библиотечного) имеет значение или нет?
Для вас по идее должен и меть.
Вы можете засчитывать что угодно, но если вместо положенных 75кБ приложение весит 75 МБ — не надо мне рассказывать, что это так и должно быть
Мне вот просто интересно, откуда вы взяли 75кб? Пальцем в небо? Или это мистическая цифра, описывающая идеальный размер кода?
Так вот, скачал-таки сберовский apk. Там действительно dex-файлы (я правда думал, что они сменят расширение, ошибся, ок). Как раз таки 75 мегабайт классов. Кода. Вы считаете это нормальным, ок.
Мне вот просто интересно, откуда вы взяли 75кб?
Взял 75МБ и поделил на 1024. Вы же хотели «прям на порядки»?
Если вам правда интересно (а не просто щеки понадувать) — я могу специально для вас написать на dap приложение со всем функционалом Сберонлайна и уместить его в 75 кБ. Сколько вы готовы проспорить? (я правда им последний раз пользовался лет 5 назад, понятия не имею что там сейчас. и мне понадобятся спеки на их хттп-апи)
C влажными фантазиями — это давайте в личку. Желательно не ко мне.
Это оборот речи))
Как раз таки 75 мегабайт классов. Кода. Вы считаете это нормальным, ок.
Большая часть объема архива — это мета данные, статика и внешние либы, а не код непосредственно приложения.
я правда им последний раз пользовался лет 5 назад, понятия не имею что там сейчас. и мне понадобятся спеки на их хттп-апи
т.е. вы не зная что нужно сделать утверждаете, что ваш код будет умещен в 75кб, просто потому что?
я могу специально для вас написать на dap приложение со всем функционалом Сберонлайна и уместить его в 75 кБ.
Очень интересно, как вы в 75кб уместите все окружение, в котором ваш dap выполняется. Так же интересно, куда вы впихнете всю статику, которой довольно много. Так же интересно, как dap поможет в распознавании QR кодов (это есть в оригинальном приложении).
Сколько вы готовы проспорить?
А есть смысл?
Большая часть объема архива — это мета данные, статика и внешние либы, а не код непосредственно приложения.
А, то есть это можно не загружать? Или нельзя? :\
75 МБ в apk сберонлайн — это только dex-файлов. executables.
Очень интересно, как вы в 75кб уместите все окружение, в котором ваш dap выполняется.
Вы, может, не знали, но в любом андроиде есть как минимум WebView, а как правило — целый Chrome. Этого для dap достаточно. Сбер же с собой весь андроид не тянет, надеюсь?
как dap поможет в распознавании QR кодов (это есть в оригинальном приложении)
В распознавании QR не поможет, но можно воспользоваться сторонним, правда?
А есть смысл?
А есть деньги?
Вы, может, не знали, но в любом андроиде есть как минимум WebView, а как правило — целый Chrome.
Это замечательно. Только в андроиде я что-то сомневаюсь, что есть:
yandex mapkit, opencv. Они уже больше 75кб весят. Шрифты и изображения тоже весят больше 75кб.
В распознавании QR не поможет, но можно воспользоваться сторонним, правда?
Конечно же можно, но размер из ваших 75кб придется вычесть.
А есть деньги?
На ваши глупости нет.
Только в андроиде я что-то сомневаюсь, что есть:
yandex mapkit, opencv. Они уже больше 75кб весят
Банкоматы на карте показывать? yandex mapkit в андроиде может и нет, но у яндекс-карт есть JS API и HTTP API
Шрифты и изображения тоже весят больше 75кб.Шрифты и изображения (и css) в мои 75кБ, разумеется, не входят. Так же как и в сберовские 75МБ dex-файлов.
Конечно же можно, но размер из ваших 75кб придется вычесть
С чего бы? Lens в андроиде искаропки есть.
Если Вы живёте в Москве, могу попробовать организовать Вам встречу, думаю если Вам удастся в одно лицо реализовать весь функционал мобильного приложения Сбербанк-Онлайн для веба в разумные (обозримые) сроки в объёме 75кБ, Вы сможете очень и очень неплохо заработать.
Сделайте презентацию, мы соберёмся, позовём архитекторов, аналитиков и разработчиков, сможете нас убедить — обсудим условия спора.
Готовы?
Меня немного настораживает вот это ваше "весь" жирными буквами. Возможно, я что-то об этом приложении не знаю, т.к. не пользуюсь им особо. Но если говорить о функционале, в принципе реализуемом в рамках браузера и http-протокола — то движок + вся ui-логика, написанная на dap, в 75 КБ я уверен, что влезет. Не считая, конечно, картинок, шрифтов и CSS. Ну и карты/qr и т.п. будут внешние.
Я прямо в понедельник начну организовывать для Вас конференцию.
OldVitus Можете отписать комментарий по результатам?
Странно, вы ведь мне предлагали то же самое на вполне серьезных щах.
Слив засчитан.
Слив засчитан.
Так я мог бы вам ответить вот в этом месте нашего диалога:
— А есть деньги?
— На ваши глупости нет.
Если бы я, конечно, был инфантильным неудачником, пытающимся поднять свою самооценку за ваш счет. Я этого не сделал, а вы, видимо, не оценили.
Так я мог бы вам ответить вот в этом месте нашего диалога
Вы часто вкладываете деньги в то, что вам ничего не принесет?
Если бы я, конечно, был инфантильным неудачником, пытающимся поднять свою самооценку за ваш счет.
Ну, это примерно так и выглядело.
Вы часто вкладываете деньги в то, что вам ничего не принесет?
Вы часто бросаетесь писать большое приложение (а 75к на dap это довольно много) забесплатно, только потому что некий пхпшник с горы, любитель воображаемых слив, усомнился в вашей способности это сделать? Серьезно? Я вам предложил спор на деньги, вы сморозились. Теперь, кстати, (раз уж в тот раз вы, извиняюсь, зассали, и момент упустили) кроме денег, я еще и апи попрошу, т.к. оказалось, что он закрытый, а реверсить его — это неинтересный совсем головняк, неуместный при живом-то инсайдере, вписавшемся за вас. Ну и ТЗ.
Копите. Накопите — пишите.
Вы часто бросаетесь писать большое приложение...
Не, я бы это даже не предлагал.
Я вам предложил спор на деньги, вы сморозились.
О чем спорить то? Вы начали вопросы правильные задавать о том, а что же входит в функциональность сбербанка онлайн когда уже слились.
Это ошибка новичка, практически каждый инженер с ней в той, или иной форме сталкивался. Ничего, дорастете до мидла — сразу такие вещи замечать будете.
Я вам предложил спор на деньги, вы сморозились.
Вы только слились на таком же споре, в чем смысл сейчас то? Сел в лужу — обтекай.
Ну я не настолько кровожаден, чтобы настаивать.
Чтобы неплохо заработать надо для начала слезть со своей голубятни или открыть наконец глаза.
Просто интересно, сколько времени Вы готовы потратить на эти 75кБ кода и что для Вас значит «неплохо заработать»
Я посмотрю на список и либо скажу — да, могу в 75кБ, либо, как вы просили: извинюсь, посыплю голову пеплом и напишу хвалебную статью про Сберонлайн, про Сбер, про Грефа и про вас лично.
UPD:
Кстати. Не в качестве хвастовства, а просто забавное совпадение. Я сейчас достаточно неплохо зарабатываю. Правда, не программированием, как вы уже знаете. А с помощью разработанного мною оборудования, которое по странному совпадению, примерно в ту же тысячу раз дешевле общепринятых аналогов, занимает ~10 раз меньшую площадь и потребляет в несколько раз меньше электричества. При этом имея те же производительность и качество продукции, на порядки меньшее время на переналадку, в разы меньшее количество отходов, и позволяя делать то, что аналоги не могут. Правда, тоже требует чуть более высокой квалификации работника. Удивительно, правда?
я могу специально для вас написать на dap приложение со всем функционалом Сберонлайна и уместить его в 75 кБ.
Я посмотрю на список и либо скажу — да, могу в 75кБ, либо, как вы просили: извинюсь, посыплю голову пеплом
Я смотрю вас уверенности поубавилось, а что так?
Список того, что я называю "весь фунуционал" распределён между десятками команд, и он постоянно растёт — agile, как ни как :)
Собирать его ради пепла мне ни к чему, но Вы можете открыть новую версию приложения и ознакомиться с ним.
«Да могу в 75кБ» — Вы уже сказали, но это громкое заявление и за него нужно отвечать.
Извинений я не просил, а требовал, поскольку Вы не захотели отвечать за свои слова.
Пепла на Вашей голове в данный момент вполне достаточно, просто Вы его не в состоянии заметить.
Хвалебные статьи Ваши тоже никому не нужны.
Лучше напишите статью про Ваше замечательное оборудование и что оно делает, это всем будет гораздо интереснее чем никому (и Вам в том числе) не нужный dap.
А сейчас Ваш UPD Выглядит как те пресловутые 75кБ.
Dap в действии. Пишем TodoMVC. Часть 1