Pull to refresh
9
0
Алексей Масленников @geeqie

Пользователь

Send message
Прошу прощения за поздний ответ. На самом деле я пытался прикрутить семантик и думал поиметь с него какую-то пользу, но в конце концов заметил, что по-прежнему пользуюсь связкой helm+projectile+grep/occur или просто highlight в буфере. Вспоминая мои короткие эксперименты с семантиком, могу лишь заметить, что он был немножко задумчив при первом открытии проекта.
Нет, но я знаю о существовании такого рода стартер-китов: spacemacs, prelude, oh-my-emacs, emacs24-starter-kit… это все хорошо, когда ты начинаешь знакомиться с редактором и хочешь быстро получить более-менее налаженную систему. Но когда ты годами собираешь по крупицам свой собственный конфиг и максимально контролируешь свои любимые режимы, то перепиливать под себя что-то существующее может оказаться затратнее, чем навелосипедить решение для своих нужд.
Так и есть, сниппеты это было давно, когда деревья были большими :) Сейчас основное внимание уделено автоматизации деплоя конфига и оптимизации скорости загрузки модулей. Я из тех олдфагов, которые не пользуются emacs-server, и предпочитают держать по пять окон редактора открытыми для различных контекстов.
Спасибо! Идею я специально не спешил выкатывать на всеобщее обозрение, решив испытать её предварительно в бою. И был очень приятно удивлен тем, как всё просто и предсказуемо работает. Поэтому покуда не перевелись ещё буквы в алфавите, будем набирать их в emacs.
Да, со временем наступает просветление, что конфиг твой это уже не просто список простых настроек, а более-менее взрослое приложение, к которому и относиться нужно соответствующе :)
Апи вконтакта всегда славилось своей костыльностью. Скольких нервов стоила только настройка авторизации по OAuth2, которая так и не смогла быть полноценно реализована из-за того, что у вк нет страницы oauth/me, которая позволяла бы идентифицировать пользователя по токену.
Если человек хочет установить себе улучшалку — пусть устанавливает. Кто определяет, является продукт свистоперделкой или нет? Для меня и твиттер, например, — свистоперделка. А для других — способ общения, зарабатывания денег итд.
В момент открытия Mac App Store многие разработчики оказались перед сложным выбором. Чтобы попасть в App Store, им необходимо было изменять приложение, урезать часть функционала, менять лицензию, покупать Mac Developer Program. В противном случае им оставалось продолжать распространять свое приложение как раньше, при этом рискуя потерять пользователей.

При этом, из-за жестких требований AppStore, многие популярные и известные приложения вообще не имеют шанса туда попасть. Так, к примеру, App Store закрыт для приложений, которые распространяются с лицензиями Open Source, MIT или CCL, а также тем, которые даже незначительно меняют системные функции или оформление. Доступ к магазину приложений также закрыт для множества популярных утилит и твиков, таких как CleanMyMac, MacHider, Magician, Adium, Skype и для многих других не менее удобных и полезных приложений.


Жуть-то какая, я и не думал, что у маководов все настолько плохо… А как раньше распространяли такой софт? Make && make install?
P.S.: Присмотревшись, понял, что мне это больше навевает какие-то ассоциации с Adobe.
Так и есть, проделал эксперимент, показав логотип своей родне (с разной степенью «компьютерной грамотности», но знакомых с яндексом). Никто не догадался с трех попыток, что это браузер или какой-либо иной продукт яндекса.
for всех вершин, for всех рёбер… мои глаза! Сделайте меня развидеть это! Это же псевдокод: пишите уже по-русски все, зачем это извращение?
Таким джуниором, как описываете Вы, я не был. Я хорошо учился в университете. Огромная доля джуниоров, с которыми мне приходилось работать, такими не были тоже. А полуграмотные обезьянки в большинстве случаев такими же и обезьянками и остаются после трудоустройства. Есть, конечно, талантливые ребята, но таким прочитать K&R обычно не составляет труда.
Да, у него определенно имеется парочка badass moves :)
Для разработчика лучше получать опыт и делать ошибки, в которые более зрелые коллеги натыкают носом, и разжуют что и как.

Именно для разработчика, а не для недоросли, которая не понимает, что происходит вообще. Такие люди тянут проект вниз, требуя (если вообще что-то пытаются понять) от коллег неоправданно много времени на растолковывание очевидных вещей и производя на свет говнокод, который ни в каком виде не годится ни для использования, ни для поддержки. Я жалею не работодателя, а разработчиков, обреченных нянчиться с такими кадрами, поскольку мне самому доводилось с этим иметь дело.

Джуниор — это программист, знающий все свои инструменты и языки, но не обладающий достаточным опытом для самостоятельного принятия проектных или прочих сложных решений. Человек же, не владеющий фундаментальными знаниями, — это не джуниор, это быдлокодер.
Можно сидеть дома и читать книжки по С, а можно пойти работать по специальности и получать ЗП. Я рекомендую второй вариант.

Можно сидеть дома и читать книжки по С, а можно пойти писать говнокод.
Если Вы, никогда не программировали, то книга Кернигана и Ритчи (в любом издании), Вам явно будет не по силам.

Если вам явно не по силам читать K&R, то вам явно еще рано претендовать на должность разработчика ПО.
Тебя здесь заминусуют хотя бы из-за того, что пользователи Vim или Emacs не читают статью про ST и Np++ :D Сам пользуюсь Emacs-ом, и зашел в комментарии, зная, что рано или поздно увижу подобный вброс. Хабр меня не подвел.

Конечно, если сравнивать то, Vim и Emacs тоже имеют свою аудиторию, обладают огромной базой плагинов и ничем не уступают ST. Все, что нужно, точно так же легко допиливается руками. Просто как-то не модненько сейчас, что-ли. Ну и да, порог вхождения у них повыше, более в программистско-гиковскую сторону (особенно отсеиваются люди после того, как понимают, что из коробки у них ничего работать не будет). Из всей нашей команды разработчиков (javascript) только я использую Emacs, подавляющее большинство сидит на ST. Однако со временем (в любом редакторе) ты обзаводишься своей парой-тройкой десятков уютненьких плагинов. Я пользователь с многолетним стажем и мне уже некомфортно пользоваться другими инструментами — кажется, что тебе вручили стилус и глинянную табличку вместо ручки и бумаги.
особенно в сравнении с асинхронной лапшой
Работая с Node.js, люди ожидают увидеть именно асинхронный код.

в моей либе используется автоматическое распарралеливание
И ты никогда не узнаешь, читая код, было ли тебе возвращено просто immediate значение, или же прилитело что-то из колбека.

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

это не годится для продакшена совершенно
Отчего же? Если не нужно писать сверхотказоустойчивую автономную систему, то вполне годится. Я еще раз подчеркну, есть лог консоли приложения и утилиты автоматического перезапуска упавшего инстанса.

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

ратовать за явную асинхронность в то время как работа с нею является самой большой болью разработчиков на ноде
Асинхронность никогда не доставляла никакой боли ни мне, ни другим разработчикам, с которыми мне приходилось работать. Откуда дровишки-то? Из статей блоггеров-хэлловорлдщиков?

всякие такие библиотеки-выравниватели реализуют лишь один вид потока — последовательное выполнение.
Все понятно: «статью не чилал, но осуждаю».

зачем их переизобретать на своём асинхронном dsl, если ест возможность дожидаться завершения асинхронных операций не теряя контекста?
Программа, может, и не потеряет контекст, но разработчик, читающий код, сойдет с ума. Write-only код — это как раз то, что не нужно для продакшена, а не вылетевший иксепшн из-за бага, который тут же пофиксят следом.
Во-первых, сложно то, что мы «ставим поток на паузу». Во-вторых, пытаться написать асинхронный код в синхронном стиле — это как раз-таки «экспериментальность». Волокна скрывают асинхронную природу кода, усложняя его понимание при чтении и поддержке. Опять же, по причине того, что код начинает выглядеть «синхронно», появляются дополнительные проблемы с параллельным выполнением асинхронных запросов, которые уже не вписываются в эту уютную концепцию и добавляют ложку дегтя в эту «прогрессивную» бочку:

console.time( 'serial' )
    console.log( get().statusCode )
    console.log( get().statusCode )
console.timeEnd( 'serial' )

console.time( 'parallel' )
    var resp1= get()
    var resp2= get()
    console.log( resp1.statusCode )
    console.log( resp2.statusCode )
console.timeEnd( 'parallel' )

Чем в этом примере отличаются последовательные вызовы от параллельных? И это пример из документации библиотеки по твоей же ссылке.

С «приятными бонусами» в виде отлова ошибок тоже спорно. Если ошибку можно обработать, то и во «Flowy» (и в любом подобном инструменте) ее можно поймать на последнем шаге. А она вылетела, пытаясь убить весь процесс, то это, видимо, ошибка, которую нужно чинить, а не отлавливать в волокнах — существует же лог консоли и утилиты наподобие forever, в конце-концов.

Прогрессивные технологии — это замечательно. Волокна, в частности, — это очень мощный в умелых руках инструмент. Но это пока что не традиционное средство, к которому привык разработчик на Node.js (да что уж там, любой разработчик), а незнакомые инструменты — это первый шаг к беспорядку в проекте и ошибкам в коде.
В ноде нет волокон. Есть плагин для реализации волокон, который является сугубо экспериментальным, сложным для понимания и практически невозможным для отладки.

Information

Rating
Does not participate
Registered
Activity