• Можно ли обойтись без jsx и зачем?
    0
    То есть этот инструмент настолько не пойми как работает, что для отладки кода с его использованием нужны десятки килобайт отладочных сообщений?

    То есть, сообщения об использовании deprecated классов/модулей/функций, различные warnings, например — это признаки плохого инструмента? Выбирая из 20Мб отладочных сообщений, и модулей ля упрощения разработки в development, и отсутствие оного, зато не требующим шага при сборке — я выберу первый. Потому что, мне это ничего не стоит. Зато это сэкономит мне время, когда палка выстрелит.


    Типы несут полезную нагрузку. Неиспользуемые модули — бесполезную. При этом типы вырезаются при любой сборке, а не требуют для продакшена делать отдельную.

    Да. Я понимаю вашу позицию. Типы вырезаются при любой сборке, а вот сделать dead code elimination, или tree shaking — это уже в самописной build системе не получится сделать за пять минут и на коленке. Поэтому это сложно, а значит не нужно. Лучше делать отладку на production с пользовательскими данными, верить в то, что используемый инструмент идеально написан, и отладочная информация для слабаков, а настройка сборки — не нужна, потому что наш инструмент ее не умеет и вообще время, и вообще сложно.


    Речь шла про TSX, он поймает.

    Но речь как раз шла не об ошибках типов, на что вы сказали, что только типизируемый язык такие ошибки словит (хотя при чем тут типы). JSX тоже их поймает. Кажется мы тут упустили нить, но уже не хочу разбираться кто и когда ее упустил.


    Чудесный костыль. Чуть более сложные внутренние контролы и это неявное соглашение ломается. Какое он имеет отношение к типизации?

    Это не костыль, это всего лишь синтаксис языка. Конечно сломается, но когда оно сломается — тогда и код перепишется. Да и тесты помогут. К типизации это относится ровно так, что TS/Flow не идеальны, и к тому, что краткость синтаксиса, не всегда доступна вместе с типизацией, и нужно выбирать.


    Кстати, насчет TS. Как думаете, вот этот код TS поймет как неправильный: function filterArray(a: any[]): number[] { return a.filter(i => typeof i === 'string'); }? Можете в Playground даже попробовать. Надеюсь, банальный filter вы костылями не назовете?


    Речь идет о формировании лога событий, предшествующих ошибке

    Представьте себе, лучше большое количество бесполезных логов, среди которых есть действия, которые могли привести к ошибке. Такие логи — дополнительный ключ к пониманию, почему произошла ошибка и где ее искать.


    Вы зашли на продакшен, видите багу. Что к ней привело — не понятно. Ваши действия?

    Так это вам непонятно, что к ней привело. Я то как раз использую "ненужные модули" и "логи про то, как пользователь поскроллил", и могу довольно быстро локализовать ошибку. У меня на руках есть исключение, привязанное к source maps (если это было исключение), у меня есть примерный сценарий поведения пользователя (потому что пользователь никогда вам не скажет, что он сделал, что привело к ошибке), и у меня есть локальная система, где я могу попытаться воспроизвести ошибку, и задействовать бесполезные модули, которые нужно вырезать на этапе сборки. Так что, первым моим действием, будет анализ данных, а не гадание на production, как воспроизвести, и почему так получилось.


    А что вы ожидали увидеть? Что вы вкладываете в понятие микромодульности, помимо отсутствия монолитного ядра?

    Я ожидал увидеть нечто из ряда вон. Я ожидал, какой-то магической "микро"-модульности. А на деле, простой компонентный подход, разделение на модули (откуда тут взялось микро — не понимаю, отсылка к модным ныне микросервисам?), который у многих уже давно.


    Реакт заменяется модулем $mol_viewer.

    Я имел ввиду не в рамках $mol, а как инструмент для решения класса задач.


    Что вы хотите там кастомизировать?

    Например, я хочу кастомизировать используемые PostCSS плагины (а кто-то использует вообще Less/Sass/Stylus — и это их право). И знаете. Не просто кастомизировать. У меня в рамках приложения, может быть допустим, несколько разных типов страниц — основные разделы для пользователя, пара SPA, админка, и пара лендингов. И для каждого я хочу свой набор PostCSS плагинов, потому что у них могут быть разные требования, или нужны по разному настроенные плагины. Или, я хочу импортировать CSS в JS, например. Я хочу, чтобы моя сборка считала зависимостью не только JS/CSS файлы, но и статику, которые те используют. И желательно, это дело тоже как-то оптимизировать. Я хочу прокидывать флаги NODE_ENV, например, но мы это проходили, да. Я хочу контроллировать, как будут собираться бандлы и иметь возможность оптимизировать стратегию их сборки и компоновки под нужды приложения. Я хочу, чтобы сборщик умел кешировать и умел в инкрементальную сборку в development, чтобы было быстро, и может быть умел hot reload. Хотел бы иметь сервер, который бы отдавал ассеты в development режиме, без нужды сбрасывать их каждый раз на диск, а отдавать прямо из памяти. Чтобы было быстро.


    Там вполне явные зависимости. Когда вы пишете $mol_defer в бандл включается модуль $mol_defer. Куда уж явнее? То, что вы имеете ввиду — не явные зависимости, а зависимости вынесенные в начало файла. Объявления переменных вы тоже в начало файла выносите?

    Ну это так себе — как явные зависимости. Если допустим, я напишу $mol_defer, но такой модуль не будет существовать — ваша сборка скажет мне об этом? А если, не будет существовать не JS файл, а какая-то другая зависимость — я об этом узнаю? Dependency Injection — механизм не явных зависимостей конечно. Но у него есть свои benefits, о которых много копий сломано, и рассказывать то, что можно прочитать в десятке мест — я не хочу. Кстати, этот же механизм есть и у Ember. И он тоже отчасти на соглашениях построен.


    Потому же почему и тут карму сливают — я не Дэн Абрамов, $mol — не React, а работаю я не в Google.

    Ну может карму сливают не потому, что вы не Абрамов (и он не всегда в FB работал), а потому что, вы можете быть не правы? Или ваше мнение не совпадает с большинством? Роману Дворнову, вот ничего не мешает рассказывать про basis.js, при этом не имея огромной аудитории как у React.

  • Можно ли обойтись без jsx и зачем?
    0
    Расскажите, что это за информация.

    Да банальная отладочная информация. Например, отладочные сообщения, ворнинги. Которые имеют смысл мне локально, но не имеют смысла в продакшене для пользователя. Мы же с этого начинали. Или опять таки propTypes, или те же типы (они бесполезны в рантайме в случае JS, увы). Мы кажется с этого начали — зачем пихать отладочную информацию, чтобы потом удалять её сборкой, разве нет?


    В таком случае разглагольствования про выявление ошибок на этапе сборки — ни о чём.

    Какая-то странная ультимативность. Type checker выявит ошибки типов (большинство, не все — он в рантайме не защитит от кривых входных данных — ошибка отловится, но уже где-то глубже, а не на точке входа). Но типы не поймают ошибку, если в es6x будет неправильный шаблон, и сборка не поймает. Так что разглагольствовать есть о чем. Кроме того, есть trade off между TS/Flow, и выразительностью, например https://twitter.com/dan_abramov/status/808020948750397441


    Он передаёт на сервер слепок памяти? Или как обычно — лишь создаёт видимость в духе "ну браузер такой-то, ось такая-то"?

    Вы отлаживаете клиентский JS по слепку памяти? =) Нет, конечно, речь идет не о банальном environment'е, что трекеры умели в бородатые годы. Речь идет о формировании лога событий, предшествующих ошибке https://trackjs.com/assets/images/tour/telemetry-full.png Я могу ошибаться (давно не пользовался), но кажется в sentry подобная штука называется Breadcrumbs.


    Лучше искать там, где воспроизводится. Вы соскочили с темы "как понять причину ошибки" на тему "как воспроизвести неуловимую ошибку".

    Правильно. Если она воспроизводится локально — то лучше её там и искать. Трогать продакшн конечно же нужно, но если можно этого избежать — почему не воспользоваться этим? =)


    Микромодульностью.

    Честно, пробежался по репозиторию, и магической микромодульности не увидел. Просто свой набор утилит + компоненты, только самописные и интегрированные между друг другом, а не с npm. Крутое решение для класса задач, но я не вижу как им заменить React, и кастомизируемую сборку. И да, я люблю конечно, convention over configuration, но так же я люблю явные зависимости. Если бы, у вас был dependency injection, аля Angular — это было бы интереснее, но у вас просто парсинг своих соглашений в поисках зависимостей, вместо import/export из es6. Ну как бы, это не микромодульность, ну или не чем-то выделяющаяся, извините.


    Что касается $mol вообще. В Питере целых два сообщества проводят митапы по фронтенд разработке. Почему бы вам не рассказать о нем на митапе? Не все пишут на React, в общем-то. Вполне вероятно вы найдете идею/критику/пользователей на них, рассказав о своем инструменте.

  • Можно ли обойтись без jsx и зачем?
    0
    Рассказываю. Это очень удобно, когда отладочная информация лежит в отдельном файле.

     Круто, расскажите как отладочную информацию положить в отдельный файл в случае обсуждаемых выше задач? Кроме source maps.


    propType — это рантайм эмуляция статической типизации. Что мешает использовать полноценную статическую типизацию в виде TSX, которую не нужно "вырезать"?

    А я не отметал возможность использования TSX, только вот, TypeScript не всем нужен и не всем нравится. Так то и FlowType есть. Но как и в случае с TS — не все используют.


    Есть много разных минификаторов. Сейчас они используются скорее по инерции, так как на фоне gzip практически ничего не дают.

    Ну не знаю. У меня почему-то, даже zopfli дает ощутимо разные результаты после и без минификации. Вы делаете слишком обобщенный вывод.


    А это вы откуда взяли? У меня сорсмапы кладутся в отдельный файл. А вы вкомпиливаете их прямо в код? Зачем?

    А с чего вы взяли, что я имею ввиду только вариант использования source maps внутри скомпилированного файла, а не как отдельного? =) Возможно, я зацепил информацию из треда ниже или выше, не напрямую к вам относящуюся.


    Хорошо там у вас наверно в идеальном мире? :-)

    Идеальный мир — делаем мы сами. TrackJS умеет в телеметрию, например. Так что, он не такой идеальный, а скорее реальный. Вы же используете, например, console.log. Ну так же вместо него можно сообщения отправлять в трекер. Лучше, чем искать ошибку на продакшене, не так ли? =)


    Правильная архитектура позволяет экономить гораздо больше.

    И как это связано с размером результирующего бандла приложения? Ну можно и System.import вспомнить, и асинхронную догрузку кусков приложения. И многих подходов. $mol тут чем особо выделяется? Тем что минималистичен?

  • Можно ли обойтись без jsx и зачем?
    0

    Кстати, еще пока вспомнил, и касательно конкретно React. В dev и production режиме, JSX транспайлится по разному. createElement против непосредственно JS объектов. Первый дает больше возможностей для отладки, второй — быстрее работает.


    Что касается разбора шаблонов непосредственно на клиенте — мы хотим дать лучший UX. Если мы можем отказаться от дополнительных шагов, и быстрее показать страницу пользователю — почему это не делать? Зачем дополнительный шаг? Есть ведь мобильные, есть простые пользователи с не совсем производительными устройствами.


    На секундочку, Angular 2, компилирует шаблоны в императивный JS-код непосредственно.


    Или вот https://svelte.technology/ от Рича Харриса (автора Rollup). Фреймворк компилирует компоненты в непосредственно императивный код.


    Технологии двигаются в сторону оптимизации, тут же предлагается компилировать шаблоны на клиенте (даже во времена классических строковых шаблонизаторов, хорошей практикой была прекомпиляция шаблонов Jade/Pug/etc в функции).


    Я уже не говорю о том, что современные редакторы умеют в подсветку JSX синтаксиса, и его легче читать, чем HTML шаблон в строке со вставками.


    Еще один момент — компиляция JSX шаблона быстрее покажет ошибку в шаблоне (просто банально не сможет распарсить структуру), нежели мы получим ошибку в runtime при попытке отрендерить страницу. В конце концов, редакторы, вполне себе уже поддерживают JSX и укажут на несоответствие синтаксиса. Это конечно, по большому счету лирика, но тем не менее.

  • Можно ли обойтись без jsx и зачем?
    +1

    Аргумент в принципе логичен с первого взгляда, но упускает множество моментов.


    Во-певрых, отдельно придумывать архитектуру внутри библиотеки, так, чтобы подключать туда расширения только для отладки — это не всегда лучшее или удачное решение. Или лучше сказать — это не всегда наилучший и единственный путь. В конце концов, вы же не рассказываете условным C++-разработчикам, что сборка бинарных файлов с отладочной информацией — это плохо, и поэтому C++ — это странный инструмент, правильно?


    Во-вторых, тот же React в development режиме вырезает не только отладочную информацию, но и например, вырезает проверку propTypes. А еще при сборке, их можно вообще вырезать из кода тем же плагином.


    В-третьих, вы упускаете момент, что например, есть, например, минификатор babili, который построен поверх babel. Babel и подобные инструменты — это не только полифилл для новых версий языка.


    В-четвертых, ECMAScript в отличии от ранних версий, сейчас активно развивается, и говорить о том, что сейчас все фичи будут во всех мажорных браузерах, и нам не нужен будет transpiler — преждевременно. Transpiler используется для проверки и реализации новых возможностей языка (в том числе, посмотрите на процесс TC-39). Во-вторых, новые возможности можно использовать уже с Stage 3 (когда допускаются только критические исправления). Но есть еще Stage 4. И это только до момента внедрения в браузеры (этот процесс тоже не равномерен по времени). То есть, transpiller позволяет подготовить ваш код к будущему переходу на нативную поддержку в движках языка до того момента, как эта поддержка настанет.


    В-пятых, отсылка на отказ от source map также преждевременна. Вы можете отказаться от babel, но вы же минифицируете код? Значит, уже нужны source map.


    В-шестых, отладка в production… Ну как бы это сказать. Этот этап должен предварять этап сбора отладочных сведений путем таких инструментов как Sentry, TrackJS, Honeybadger, и других. И потом уже можете воспроизводить неисправность локально, зная условия, которые приводят к ошибке. В 99.99% случаев, проблема будет не в сборке.


    Transpiler'ы — это данность, поэтому и отказ от JSX, только потому что он требует transpiler'а, который скоро будет не нужен — это слабый, на самом деле, аргумент.


    Я уже не говорю о том, что, экономить килобайты важно до сих пор. По очень многим причинам. Странно это вообще объяснять фронтенд-разработчику, не находите?

  • Bootstrap 4 вышел в alpha версии
    0
    Он уже стал
  • Почему я не испытываю неприязни к Git: скрытая целостность
    +3
    Это точно Atom. Характерная иконка корня проекта, характерная подсветка дерева файлов, характерная оранжевая иконка незакомиченных изменений внизу справа.

    У Саблайма статус бар на все окно, а Atom сайдбар на всю высоту, и под ним нет статус бара. Тема стандартная темная.
  • Все уже украдено до нас
    0
    Люди мучаются не потому что, Angular или React плох, а потому что не умеют выбирать инструменты для задачи и ведутся на маркетинг и хайп. Для своих задач и Angular, и React отлично подходят. Но когда вы молоток начинаете использовать, чтобы закручивать гайки, а не гвозди забивать — то тут конечно мучения начинаются.
  • Pundle — bundler для python
    +1
    Так вы продайте вашим разрабам chruby, или на худой конец rbenv. RVM конечно монстр, и устарел — но многие до сих пор по банальной инерции им пользуются.
  • Javascript: фрактал отсоса
    0
    Что-то не посмотрел на дату публикации. Некрофилией страдаю =(
  • Javascript: фрактал отсоса
    0
    Проблема сильно глубже. У Dart/AtScript/TypeScript строгая статическая типизация. Статическая типизация накладывает ограничения на скорость разработки, а также на качество проектируемой архитектуры. Учитывая средний уровень подготовки типичного JS программиста — такой программист с задачей тупо не справится.

    А вышеуказанные языки разрабатываются как правило под влиянием ребят, знакомых с Java/C++/C#, и разработка на этих языках для них не является проблемой.

    Идеальным решением было бы сделать строгую динамическую типизацию (как в Ruby или Python). Но вот загвоздка. Без вмешательства в интерпретатор, такую типизацию сделать крайне сложно, и реализация ее на уровне компиляции будет более затратной в плане производительности, чем даже типизация в рантайме у того же AtScript. AtScript может позволить себе вставить условие проверки соответствия переменной конкретному типу в конкретном месте кода. В случае же с динамической типизацией, информацию о типе придется таскать с собой, и проверять соответствия типов при каждой маломальской операции. Это будет занимать наверное 60-80% времени исполнения кода.

    Так что, увы — слабая типизация — это бремя языка, которое он будет нести наверное вечно, если все же разработчики интерпретаторов не озаботятся этим вопросом, и не найдут пути плавного перехода на эту схему.

  • Изображения в верстке. Хватит это терпеть
    +2
    Добавлю свои пять копеек:
    1) использование шрифтов для иконок чревато проблемами, но это не критично в некоторых случаях. Но я бы предпочел таки SVG, чем именно шрифт;
    2) я удивлен, почему на каждом углу говорят про Avocode, который еле вышел, как я уже несколько месяцев благополучно пользуюсь убийцей PS непосредственно от Adobe — projectparfait.adobe.com. Project Parfait бесплатный, если все подумали, что сейчас придется еще что-то платить.
  • Начало продаж Sony Xperia Z1 Compact
    0
    Спасибо, что поправили =)

    Когда покупал еще свой Z1, и уже появлялись новости о Z1 Compact, говорилось, что в новой модели наконец заменят тип дисплея.
  • Начало продаж Sony Xperia Z1 Compact
    0
    Телефоны Sony, которые выпускались до Z1 Compact, включая и старшего брата Z1, оснащены не IPS, а TFT матрицей. Z1 Compact, если я не ошибаюсь, первый их телефон, который поставляется именно с IPS матрицей, которая обладает лучшими характеристиками как по цветопередаче, так и по углам обзора.
  • Backbone.Component — автономные компоненты UI для Backbone.js
    0
    Я не могу понять, чем ваше решение + Mutation Observer кардинально отличается от React?

    Какая разница, что вы вызовете в методе render вашей Backbone.View. Вызовете вы рендер своего Backbone.Component или вызовете renderComponent React'а — суть никак не поменяется. В обоих случаях получаются черные ящики, которые внутри себя несут логику + верстку, и могут генерировать какие-то события во вне, чтобы например Backbone View могла на них реагировать, не вникая во внутреннюю реализацию.

    Если в какой-то вьюхе вам не нужен шаблон — не используйте ни шаблон, ни React компонент. Если вам не нужна манипуляция с DOM — не используйте ее. Ваша библиотека отличается от React только названием и тем, что практически ничего не умеет, ну и легче по весу за счет этого, ОК.
  • Backbone.Component — автономные компоненты UI для Backbone.js
    0
    Что? А вы не путаете теплое с мягким?

    React это:
    — библиотека, а не фреймворк;
    — это V в MVC, поэтому с Backbone и используют.

    И главное, что собственная идеология React заключается в том, чтобы не мешаться внутри приложения, а помогать его строить. Именно поэтому, это библиотека с совершенно четкой и единственной целью. И используется она для создания как раз веб-компонентов, подобно Google Polymer. Ну и по сути это тоже самое, о чем написано в посте.
  • Backbone.Component — автономные компоненты UI для Backbone.js
    0
    Скажите, а в чем проблема была с тем, чтобы просто прикрутить React.js в качестве библиотеки для таких компонентов? Она то лучше ваших велосипедов, и десятка других, которые есть на рынке. Ну и кроме того, это только библиотека компонентов, и не заставляет отказываться от бекбона, или того, что вы используете.
  • Загрузка модуля по требованию в AngularJS
    0
    Ну так да, случай с огромными одностраничными я понимаю. Думал, может у кого-то еще какие-то кейсы есть.
  • Загрузка модуля по требованию в AngularJS
    0
    А что мешает разбивать приложение на модули (даже если они не связаны), загружать клиенту один раз большим (или несколькими поменьше — там в зависимости от) файлом, и кешировать это у него же (я имею ввиду инструменты подобные assets pipeline из Rails)? Тем более, так будет даже быстрее, чем за каждым мелким файлом обращаться к серверу, тратить время на коннект, ждать загрузки, и только потом получать полезный профит от непосредственно кода?

    Есть еще какие-то причины такой вот ленивой загрузки?
  • Загрузка модуля по требованию в AngularJS
    +3
    Меня всегда волновал вопрос, зачем люди используют ленивую загрузку по сети. Ну, вот например, многие обосновывали мне использование require.js или AMD.js — мол модули, мы без них жить не можем, а тут они есть и это круто. Ок.

    Здесь я вижу пример, когда даже CommonJS не поддерживается, усложняется код, делается более шатким. И меня очень волнует вопрос, зачем это надо, и чем это хуже, нежели соединить все файлы в один (или несколько больших), минифицировать их, и со спокойной душой отдавать это клиенту один раз, и не париться насчет кеширования, задержек в интерфейсе из-за лишних загрузок, и так далее.

    В каких особенных ситуациях нужны вот такие костыли (вероятно они есть, но лично я их никогда не встречал, ну разве что чистейший SPA, и то это довольно редко обоснованный случай)?
  • Несколько JavaScript хаков для хипстеров
    0
    1) это был сарказм
    2) Простите, но вы мне подсовываете тривиальный код, который легко парсить и индексировать. А как вам пример с метапрограммированием на Ruby? Где методы класса могут генерироваться на лету? Как по вашему в данном случае будет работать автодополнение? Похожие вещи есть и в других языках. В том же Javascript.

    Собственно, поэтому я и говорил, что корректный автокомплит сильно зависит от языка.
    4) смотрим абзац выше — все сильно зависит от языка. Про дело вкуса я говорил в отношении остальных методов базовой навигации.

    Я согласен, что удобно ходить по клику к переменной, но это не всегда возможно. Если вы говорите о PHP, C++, Java — я согласен, там это может сработать очень хорошо.
    5) Может быть в случае с PHP в IDE работать удобнее, но RubyMine пока не научилась работать с Pry, например. Хотя ребята проделывают огромную работу по интеграции с дебаггером. Но это опять таки дело привычки, и используемых инструментов. В вашем случае, у вас нет интерактивной консоли, с которой вы бы могли работать с запущенным живым кодом. А в моем случае такое есть. И я не просто могу дебажить, но я могу изучать структуру кода в рантайме, следить за окружением и даже просматривать исходники методов конкретного объекта прямо в интерактивной консоли Ruby с помощью этого pry. То есть, в этом плане, для меня IDE проигрывает.

    Тот же Javascript можно отлично отлаживать в браузере, причем для меня это крайне предпочтительный вариант, так как я провожу отладку непосредственно там, где мой код будет работать.

    Опять приходим к тому же — все зависит от используемого языка.
    6) Опять же, возвращаюсь к тому, о чем я говорил в первом пункте. Все зависит от языка. Да и рефакторинг, это не только переименование класса/метода/модуля/переменной.
  • Как мы делали API для социальной сети (REST API для WEB)
    0
    www.designinghypermediaapis.com/ и целая книга от Стива Клабника
  • Как мы делали API для социальной сети (REST API для WEB)
    +2
    Есть сайт. У него статьи. У статьи помимо присущих данных, есть read-only поле счетчика просмотров, которое инкрементирует внутренняя бизнес-логика приложения, при запросе на просмотр например. Пользователь данные не отправляет.

    При запросе коллекции статей — мы получаем список статей с их счетчиками. В чем проблема?
  • Несколько JavaScript хаков для хипстеров
    –2
    1) он действительно плохой
    2) простите, но индексацию по файлу умеет и Sublime из коробки, или просто прикручивается ctags к тому же vim'у. Автокомплит — это годная штука только тогда, когда у нас статически типизированный компилируемый язык, или язык, который на основе статического анализа позволяет вывести тип переменной. В любом другом случае — это индексация, и ни разу не крутая фича IDE;
    3) у меня Fedora 19, Core i3 2.4, RAM 8Гб — тормозит безбожно, хотя проекты над которыми работают жрут не меньше ресурсов, написаны на языке более медленном, но при этом работают на ура (проекты здоровые, написаны на Ruby и Rails);
    4) дело вкуса, но тот же саблайм умеет навигацию не хуже, чем любая IDE;
    5) Для дебага не обязательно иметь под рукой тяжеленную IDE, ради интеграции отладчика с этой самой IDE, где можно поелозить мышкой по вкладочкам;
    6) Как было сказано для пункта 2 — определить тип переменной в динамическом языке на основе статического анализа кода практически невозможно, а значит и весь рефакторинг в большинстве случаев сводится к обычному бездумному Найти/Заменить. Без ручного контроля не обойтись, а иногда только руками и возможно

    Так скажите, зачем мне IDE, если я вполне комфортно живу без нее, и моя продуктивность не снижается от этого?
  • Как мы делали API для социальной сети (REST API для WEB)
    –1
    Зачем ломать мозг, чтобы понять ФП? Каким образом связано ФП и Haskell в плане суждения об общем по частному? Вы уверены, что хотя бы правильно понимаете понятие ФП?

    Чтобы построить хороший RPC нужно ломать мозг еще сильнее, так как RPC не имеет никаких ограничений, и полностью полагается на добросовестность разработчика в том плане, что он будет проектировать API, а не лепить бекенд код так, как ему удобно (что очень легко делать в RPC ввиду отсутствия ограничений, подобных тем, что присутствуют в REST).
  • Несколько JavaScript хаков для хипстеров
    –1
    А что есть в IDE, без чего жить нельзя в редакторе, например, в Vim, Sublime или Emacs?
  • Как мы делали API для социальной сети (REST API для WEB)
    0
    Да, моя ошибка, не собран сегодня.
  • Как мы делали API для социальной сети (REST API для WEB)
    0
    В стандарте какой версии? POST — это создание, PUT — обновление (полное), или создание (если ресурс не существует), а PATCH — частичное изменение существующего ресурса. Стандарт HTTP 1.1.

    Но для API, мне кажется больше подходит Rails подход. POST — создание, PATCH — обновление. Это упрощает API, плюс при таком подходе, PUT становится частным случаем PATCH.
  • Twitter следит за тобой, анонимус
    –1
    Ага. А на сайтах давайте вешать «Включить Google Analytics?».
  • Twitter следит за тобой, анонимус
    –1
    Я считаю, что такую информацию обязательно должно собирать и анализировать не только любое официальное приложение, но и вообще любое приложение, которое стремится к улучшению в отношении пользователя, к улучшению в плане юзабилити и понимания того, как себя пользователь ведет и что ему надо.

    Это такая же очевидная вещь, как Google Analytics или Яндекс.Метрика на любом вменяемом сайте.

    В конце концов, они собирают не секретную информацию, чтобы удивляться, как это было в приведенной в тексте статье о телевизорах LG.
  • Twitter следит за тобой, анонимус
    –4
    А вы случаем пользу, с очевидностью не путаете? (=
  • Я перешел на Ubuntu и не… жалею?
    0
    Лично у меня, может быть руки кривые, но работала она не совсем стабильно. Установщик, например, в половине случаев не работал, или надо было догадываться, что не так делаешь. Собственно, разработчики Fedora сами это признают.

    К этому я отношусь нормально, над дистром работают, меняют, и меняют в лучшую сторону. Просто для меня стабильности не хватило.

    Xinerama у меня не заводится, как собственно и проприетарные дрова не шибко то работают. Все работает на открытых дровах от ATI, и работает шикарно. XFCE тоже не прижился, а Gnome 3 допилили до вменяемого состояния, и с нетерпением жду fedora 20 со свежим гномом.
  • Я перешел на Ubuntu и не… жалею?
    +1
    Я перелез. Счастлив. Особенно, радует стабильность 19 версии (18 была провальна, и сидел на убунте). Железо держит вообще на ура, особенно системы с несколькими мониторами (ноутбук + 2 внешних). Win8 умеет их понимать сразу после загрузки, в убунте вообще были шикарные проблемы, на Fedore они все включаются еще на этапе загрузки. Это как один из примеров.
  • Retinafy everything
    +1
    Вам стоит перечитать внимательно пост, и ответить на один вопрос: вы графики, подобные как на странице D3 скажем, тоже руками на сервере генерируете? И делаете это за то же время, за которое их можно сделать на d3 или raphael?
  • SVG.js — достойный конкурент Raphaël
    +1
    Тем более! (=
  • SVG.js — достойный конкурент Raphaël
    0
    Вы привели лишь один из многих контекстов. В языке у слова может быть десяток значений, которые работают в тех или иных контекстах. Да взять, хотя бы, тот же английский язык, где это сильно выражено, за счет малого количества слов в языке (в отличии от богатого русского языка).

    Язык, в первую очередь, решает задачу коммуникации. И если, педантичность мешает этой задаче, то она уходит на второй план. С логической точки зрения, ваше мнение абсолютно верно. Но, вы же прекрасно поняли, что автор статьи под словом «ретина» имел ввиду как раз «дисплей с высоким разрешением». Язык выполнил свою цель. Донес до вас смысл, при этом наименее кратким способом.
  • SVG.js — достойный конкурент Raphaël
    0
    Для многих русскоговорящих, ретина уже давно превратилась из маркетингового названия Apple, в слово, которым удобно такие дисплеи называть. И многим уже, мягко говоря, без разницы от кого это устройство.
  • SVG.js — достойный конкурент Raphaël
    +6
    может быть потому что «ретина» — это одно слово, а «дисплей с высоким разрешением» — это три слова, не?
  • Github визуализирует изменение кода 3D-моделей
    +4
  • Semantic UI — почти альтернатива Bootstrap
    +2
    Он позиционируется не для админок, а для разработки.