• Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»
    +3
    Да, статья мне в целом на 90% понравилась но этот момент покоробил. Я, как программист работавший с до cvs-эры, перешёл на CVS, потом на Subversion, потом на Mercurial и git могу сказать что с этой перспективы мне жаль что git стал намного популярнее, потому как в с hg работать легче и система сама более понятная и удобная. Важно для меня — в hg сложнее «выстрелить себе в ногу» — тут историю не затрёшь, в то время как в git это поставлено на поток, у пользователя полный контроль (во flow с rebase для ветки, так вообще постоянно это делают, но рискуют тем, что при неадекватных действиях пользователя, затереть часть истории, а часто вы встречали программистов которые на 100% хорошо понимают что они делают с git? я — не часто).

    Работая на проектах и с hg и с git, могу сказать что по функционалу они пересекаются на 90%, при этом функционал mercurial в целом шире, но из за того что система непопулярна, сложно найти адекватную поддержку в тулзах (github, gitlab и тп только для git, потому приходиться юзать другие, менее удобные пакеты и сайты) и это большой минус. Ну и второй минус прилагается — программистам сложно переключаться, все привыкли к git, и внедрить hg в другой компании — шансы близки к нулю, при всех очевидных для меня преимуществах.

    В общем автор тут не прав, но видимо что то пошло у него не так. А статья хорошая, спасибо!
  • Вы — не Google
    +3
    > Найдите специалиста по незнакомой платформе и оплатите консультацию

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

    Так бывает достаточно часто — над проектами работают сложившеяся команды. Да, конечно же удобно когда те технологии, которые полностью знакомы команде совпадают с текущими задачами, но что делать если нет? Сразу вот так вот менять команду? Добавлять/менять специалистов? Время и ресурсы потраченные на это часто превысят расходы на до-обучение текущих.

    Мы обычно сами пытаемся решить возникающие трудности, привлекаем специалистов для коротких консультаций, но честно, этих специалистов-архитекторов не очень то и много, и почти никто не занимается фрилансом, т е в выгодном свете здесь стоит корпоративная разработка, где есть пул архитекторов решений, а для маленьких команд проще всё таки опираться на свои силы.

    Ну и главное — почти все решения не окончательны. Всегда можно что то попробовать, fail fast, и вернуться на правильный путь. Путём небольших экспериментов продвигаться к цели.
  • Как делать больше, уставая меньше. Emacs pomidor
    0
    Хочу добавить то, что я сам пробовал поначалу по 25 минут, но как то не шло. Потом нашёл исследование на эту тему: http://lifehacker.com/52-minute-work-17-minute-break-is-the-ideal-productivi-1616541102 http://blog.desktime.com/2014/08/20/the-secret-of-the-10-most-productive-people-breaking/ и понял что 25 минут это не моё, а вот 52 минуты как работают намного лучше
  • Тестируем вёрстку правильно
    0
    Есть пересекающаяся тема по автоматизации тестирования верстки: — visual diffing tools: webdiff, dpxdt, etc.
    https://www.youtube.com/watch?v=jUUTqgzNR3M с конференции по Пайтон 2015 и слайды http://bit.ly/pycon2015-visual-diffs
  • Целенаправленная и сознательная деавтоматизация бизнеса
    0
    Очень хорошая статья, и правильно акцентирует внимание на том, что кое где автоматизацией переавтоматизировали до неадекватности. Но прошу также обратить внимание на то, что люди все разные. И кое кто предпочитает живое общение (и возможно таких больше), но меня очень сильно раздражают вот эти вот «перезвоны»: «В большинстве случаев мы позвоним (методом живой девушки из колл-центра)» — это просто сильно меня напрягает, когда ты сидишь, полностью сосредоточенный на работе, и тут, бабах, звонит полуробот получеловек ( который просто обязан зачитать тебе весь список) и начинает перечислять все товары которые я добавил в корзину. Я стоически переношу это хотя раньше пробовал жаловаться в компанию, но они этого не понимают. Не понимают что мне неинтересно слушать то, что и я так знаю. И ещё набираются наглости попытаться предолжить мне 2-3 сопутствующих товара… Как же это достало. А потом ещё возможно перезвонят и спросят доволен ли я работой оператора…
  • Vim по полной: Введение
    0
    Советую присмотреться к projectile, helm. И то и другое дали очередной прирост производительности лично мне. Потом если в dired научиться пользоваться выборками/глобальными заменами вообще круто получается.
  • Vim по полной: Введение
    +1
    Я тут, яволь! ;-) В emacs всего хватает, если говорить о Python: есть быстрые переходы по классам, свойствам, файлам. По файлам|каталогам проекта. Автоматическое завершение ввода (3+ способами). Доступ к документации ЯП прямо из. Доступ к snippets, ну и так далее по списку. В emacs самая большая проблема наверное то, что всё вместе настроить и запомнить куда какая кнопка — нетривиальная задача, это многих отпугивает
  • Как я был идеальным заказчиком
    0
    Да. По сути — они работают в своей области более 15ти лет, перепробовали кучу ПО, решили писать своё. Как смогли нарисовали экраны и выдали нам полную спецификацию (говорили что знают всё на 100%). Но по сути, они не программисты, а продвинутые пользователи. Т е многие вещей, из за того что другие программы на аналогичную тему были не продуманы до конца, они не видели. В процессе работы предоставленные нам UI mockups сработали против проекта — так как вначале нас «нагнули» на то чтобы мы сделали «как они хотят» 1:1, а потом уже, когда к нам сформировался кредит доверия, мы постепенно вывели систему на нормальные рельсы, упростив и выбросив многие ненужные сложности. Т е на первом этапе работ, во время «сработки» были серьёзные проблемы. А сейчас всё наоборот — любые фичи и дополнения _вначале_ обсуждаются, думаем есть ли другие варианты (мозговой штурм) и потом уже принимаем совместно созданный дизайн в разработку.
  • Как я был идеальным заказчиком
    0
    Очень хорошо написано, и главное в точку. Многие описания неадекватных заказчиков — это то, с чем мне приходиться иметь дело непосредственно сейчас.

    Я несколько раз сталкивался с ситуацией когда «заказчик точно знает что хочет и уже нарисовал UI». Это не работает. Причина банальна — у исполнителей просто может быть немного другое видение и другие подходы, и не всегда эти подходы будут совпадать. Мы недавно разрабатывали проект для компании которая постоянно настаивала на том что они до детаей знают как _это_ должно работать, но на деле, оказалось что многие бизнес процессы были неоптимальны. Закачики «знали досконально как» в рамках того процесса, который у них уже построен, но при адекватном рассмотрении и совместном планировании многие бизнес процессы реально упростились, выдав немного другой результат чем был прорисован на начальных экранах, но в общем к взаимной выгоде как заказчика так и нашей. Хорошее ПО рождается в процессе взаимного обмена знаниями. Просто «закодировать» экраны и бизнес логику — часто скучно, и главное — не несёт позитивной нагнузки. Тупые кодеры скорее всего не въедут в смысл задачи и это послужит почвой для массы недоработок в процессе, а умные кодеры просто не возьмуться за задачку где «всё уже решено».
  • Yii, непрерывная интеграция — как не сломать все
    0
    5xx — не нужно фаталить при кривых запросах, нужно давать пользователю осмысленную ошибку “что он делает не так”.

    Спорный подход. Если хакер занимается подбором параметров чего бы поломать в системе, ему тоже писать осмысленную ошибку «что он делает не так»? Я специально ставлю по коду asserts, главное предназначение которых не дать разработчику криво вызвать функцию. Естественно для конечного пользователя идут обработки исключительных ситуаций и показываются ему ошибки, но только до тех пор, пока пользователь соблюдает протокол общение и не лезет в переменные GET/POST. Если программа вызывается способом, не предусмотренным разработчиками, ошибка обязательно должна быть, она должна прийти нам в Sentry, подлежит дальшейшему анализу и мы уже решаем что делать дальше — насколько вменяема и возможна данная ситуация, была ли попытка взлома и что делать дальше. Главное тут в том, что ошибки 500 показывают нам действительно внутренние ошибки…
  • «Сверкающие кинжалы» или как мы арабский проект делали
    +4
    Мой опыт — был один крупный заказчик из арабского мира. Сделали им несколько программ и в принципе работали бы дальше но у меня просто не было желания особо продолжать сотрудничество в таком стиле, благо заказов других хватает. По сути все проекты что мы делали: (1) отсутствие чёткого тех задания. только общее видение вопроса. — по идее для нас это не проблема т к мы работаем на почасовке на всех наших проектах. И хотя были попытки узнать финальную сумму и держаться в её рамках в процессе работы — я им предявлял вопрос — а где «финальное техзадание, которое никто менять не будет». Т к ответа не следовало, работали по agile. В общем это показало себя хорошо для борьбы с бардаком в спецификациях. (2) Очень арабы любят торговаться. Это большой минус для меня т к я торговаться не люблю. Т е нашла коса на камень — по идее хороший менеджер должен бы поддержить «игру» и поторготоваться о сроках, цене и много другом, у меня же был разговор простой — «не нравиться» — ищите того кто нравиться. Мы работаем на почасовке и никуда не торопимся. Если требуется «срочно» — цену умножаем на 2, на3, на 4. и работаем. В принципе иногда так и делали и по цене в в4 раза выше обычной почасовки работали по ночам. (3) Когда надо срочно — и деньги, и обещания золотых гор присутствует. Когад работа сделана и сдана можно годами добиваться оплаты. Потому — единственный способ борьбы — если надо «срочно и вчера» — деньги вперёд. При отсутствии предоплаты после пары задержек за предыдущие проекты мы просто отказываалсь работать. В общем работать можно, но уж очень на нервы действуют эти все тонкости. Ритм работы не тот — то срочно и всё пропало, то тишина и отстуствие ответов на важные для проекта вопросы. Учитывая то что работа в таком ритме плохо вписывается в нормальный ритм жизни проектов больше не брали, даже когда очень просили. Да и тупость или недалёкость менеджеров иногда поражает. Вроде умный человек и много чё знает, но умудрился поставить пароль на одну админку с базой в пару сотен тысяч закачиков — как он считает «достаточно защищённый» — своё имя с большой буквы. Когда «злобные хакеры» взломали систему и положили сервер, лишив части арабского мира очень важного сервиса, он вначале гнал на то что программа нресекюрная, когда докопались до деталей «взлома» чё то замолчал. Деньги по результатам «инветигейшна и фикса» нам так и не выплатили. Короче нафиг таких заказчиков. Появлялся потом через год с новым «золотым» проектом, был послан в сторону Elance и иже с ними.
  • Обзор зарядного устройства TechnoLine BC-700, или мой опыт восстановления Ni-MH аккумуляторов
    0
    Вот что мне непонятно, в этой статье автор пишет:
    Разряженные элементы питания хранятся, практически, не теряя емкость. (Об этом я, к сожалению, узнал очень поздно.)


    А на Wikipedia говорят

    Аккумуляторы нужно хранить полностью заряженными в холодильнике, но не ниже 0 градусов


    Как всё таки правильнее?

    Погуглил ещё, тоже вроде пишут что заряженными, вот и тут
    Хранить Ni-MH аккумуляторы допускается только полностью заряженными. Никогда не храните Ваши NiMH аккумуляторы разряженными длительное время (5 дней и более). Такое длительное хранение в разряженном виде увеличивает внутреннее сопротивление и. соответственно, уменьшает емкость аккумуляторов.

  • Hetzner может неожиданно отключить ваш сервер
    0
    так у нас и так на один порт один мак адрес и один реальный IP. Чё то подозреваю что кто то в том же VLAN занимался spoof, поставили наш mac адрес, а Hetzner не разбираясь нас отрубили. Меня в этой всей ситуции целиком вывело из себя не то, что отключили не разобравшись, а то, что не смогли разобраться и включить кого надо. В результате несколько дней сервер был без сети а мы восстанавливались на бекапе.
  • Hetzner может неожиданно отключить ваш сервер
    0
    У Hetzner есть система отключения сервера за несоответствуютщий конент, и в том случае действительно даётся 24 часа на разбор полётов, а в дальнейшем, после блокирования сервера для всех, всё же остаётся возможность из панели установить определённый IP адрес и зайти с него, чтобы проблему пофиксить. А в данном случае никаких шансов у нас не было — просто отключили, а потом уже письма стали писать.
  • Язык vs инструмент
    +2
    Бывает так, что писать на определённом языке без IDE достаточно сложно, например на Java. Но чаще всего набора средств расширяемого текстового редактора достаточно для продуктивной разработки, особенно если вы ими хорошо владаете. Я например, инвестировав много времени в изучение фич и особенностей одного редактора могу спокойно работать с Perl, Python, Ruby, C, C++, Javascript, CSS, HTML. Средства отладки (pdb, etc)- доступны. Средства рефакторинга тоже есть в редакторе. Поиск файлов, подстрок, и определений тоже реализован. Всякие там букмарки, быстрые переходы, ссылки, и т п. Т е есть готовый инструментарий, для того чтобы делать 80% функционала IDE в редакторе.Ведь в конце концов по моему то ли 80 то ли 90 процентов времени программист тратит не на непосредственное написание кода, а на чтение кода. При чтении кода чаще всего нужно уметь найти точку определения чего лидо (rgrep либо tags) и быстро перейти на определение (tags). При написании — удобно использовать готовые шаблоны, в моём редакторе это yasnippet. Ну и главное, при должном умении и упорстве можно этот самый редактор расширить почти до функционала IDE. Кто не догадался, это Emacs.
  • Hetzner может неожиданно отключить ваш сервер
    +2
    Так я прямо их и спросил: уверены ли что трафик идёт с нашего VLAN. Прямого ответа на этот вопрос не было.
  • Hetzner может неожиданно отключить ваш сервер
    +5
    «Другими словами, Ваших ошибок тут полон огород». Та я так и написал в начале. Да, мы в курсе своих проблем. То что мы не получили предупреждение о проблеме почтой — наша проблема, наш email не был прописан в тот момент. По поводу блокировок MAC — даже если была блокировка мака на порту — и что? Маки то наши… А вот если два мака в сети — эффект будет как раз как у нас… «3+ года у них», — а мы уже более 5ти лет, и есть сетапы со стойками серверов с отдельными switch, прыгающим IP и многим другим, и тоже всё работает как часы. Когда работает — никто не спорит, а вот показывает себя саппорт только тогда, когда возникает реальная проблема. И вообще эта статья это не попытка облить Hetzner грязью, а сделать выводы. Выводы для себя мы сделали, вот делюсь этими выводами с остальными, как бы банально они не звучали: бекапы, быстрый deployment, и правильный экономический расчёт должны иметь место. Хотелось бы надеятся на лучший саппорт, но какой есть такой уж есть. По крайней мере он есть.
  • Hetzner может неожиданно отключить ваш сервер
    +2
    После этого случая я задумался о том что пора переходить на следующий уровень — не просто делать бекапы, а ещё научится их быстро разворачивать. И бекапы у нас были, как выяснилось не все, а 95%, а это обидно т к 5% отсуствующих данных могут серьёзно усложнить жизнь. Например весь сайт был а SSL сертификат не бекапился, пришлось срочно дёргать заказчика чтобы он забрал с godaddy. Ну хотя бы _почти_ всё заработало. Бекапы надо не просто делать а ещё периодически проверять насколько они работают. В случае же с этим сайтом — посещаемость — 3-5тысяч visits/day, надо было поднимать быстро, а там надо ставить django, mysql, postgresql, celery, redis, exim, настраивать домены и многое другое… В общем сам процесс подъёма из бекапа занял несколько часов, увы, надо похоже инвестировать в deploy scripts.
  • Hetzner может неожиданно отключить ваш сервер
    0
    В посте все маки и адреса изменены. Но да, то что прислали почтой, в письме был наш MAC. Но как то проверить это с помощью tcpdump у нас не получалось с KVM т к порт был в down. Т е действительно ли приходили пакеты с нашей машины или с какой то другой с тем же mac address не было возможно.
  • Hetzner может неожиданно отключить ваш сервер
    0
    В процессе общения ещё тогда написал им письмо где чётко указал что без их помощи в данной ситуации нам не разобраться о очень нужен администратор с их стороны. На что был ответ что я с администратором и говорю, а всё что им надо это чтобы мы сами решили проблему и выслали им скан или факс об этом. Возможно у них вообще стоят неуправляемые свитчи так что на вопрос о VLAN ответа тоже не последовало.
  • Emacs и Python (статья 2 из цикла)
    0
    на emacs 24 только недавно перешёл, не переходил на package, но возможно попробую на новом компе.
    В Gentoo очень хорошая система управления пакетами, там 95% emacs-packages есть, ставяться легко, потому и особой необходимости не назрело.
  • Emacs и Python (статья 2 из цикла)
    +1
    Да. Нет в той модели UI, что применена в emacs возможности нарисовать вертикальную черту.

    Те поделки на Lisp что есть существенно тормозят, сам же engine не предоставляет такого интерфейса. Впрочем я не сильно переживаю, это из разряда фич «было бы неплохо». Сейчас всё равно идёт «общая» проверка синтаксиса в т ч и на long lines так что функционально всё есть, просто по другому, менее визуально.
  • Emacs и Python (статья 2 из цикла)
    0
    та да, мне тоже очень нравиться Sublime. денег на лицензию не жалко, жалко будет если что нибудь случиться с автором либо процессом разработки… если бы у него была хотя бы double license, пользовался бы с удовольствием, и допиливал бы на Python plugins тот функционал, к которому привык в emacs. Но, учитывая полное отсутствие сорцов в Sublime меня напрягает тратить свое время на него — я уже несколько раз в жизни обжигался, инвестировав своё время в чужой продукт. По функционалу Sublime мне наверное ближе всего к тому, что здесь описано. Vim правда тоже умеет много чего и местами больше. Остальные редакторы недотягивают. По средам лучшая коммерческая альтернатива emacs/python: PyCharm.
  • Emacs и Python, Python и Emacs
    0
    набираешь конанду emacs:
    customize-group htmlize
    а потом в перменной Htmlize Output Type выставить соответственно `font`
  • Linux-ноутбук, спроектированный для разработчиков
    0
    Я большой многолетний фан ноутбуков Dell, и всегда работаю только в Linux. Но Studio для Linux? Явно не самый удачный выбор… начнём с NVIDIA GeForce — последенее время я сильно разочаровался в обоих лидерах рынка — и Nvidia и ATI выпускают не самые лучшие устройства в плане совместимости с Linux. Постоянно из года в год одни и те же проблемы. С Intel проблем в десятки раз меньше. А глянец? По моему глянец или матовое — дело сугубо индивидуальное, тут в основном речь если нужна хорошая передача цветов (а такая бывает на t-n матрице) — лучше глянец. Если надо работать в разных условиях с разной освещенностью — однозначно матовое покрытие. Т е если судить с такой точки зрения то для разработчиков глянец — неудобно. Пару лет проработал на таком ноутбуке и больше никогда в жизни не куплю себе глянец. Некоторые владельцы Mac Book Air у нас честно завидуют моему Dell Vostro с матовым экраном.

    Вообщем по моему схалтурили в компании Dell. Я понимаю ситуация происходила как то так: «надо выпустить ноутбук для Linux юзеров». — Какой там у нас недорогой и мощный? Studio?: Ok, Определились. Нет чтобы подобрать hardware для этой цели, а так… Фигня в общем
  • Linux-ноутбук, спроектированный для разработчиков
    +1
    Я тоже долго не мог понять зачем в Python ограничили длинну строки в 80 символов. Поначалу думал что атавизм какой то, на современных мониторах можно намного больше. А тут недавно читал книжку по психологии дизайна (100 Things Every Designer Needs to Know About People) и там чётко дано разъяснение: по проведенному исследованию большинство людей предпочитают читать текст в 100 символов но при этом воспринимают (т е быстрее понимают) лучше текст в 80 символов. После понимания этого факта полностью поддерживаю разработчиков Python в этом ограничении.
  • Как положить спасибо в карман
    +1
    Супер видео! Огромное спасибо! Тут как раз веду борьбу с заказчиком который хочет привязать зарплату к уровню достижения организацией определённых (читай маркетинговых) целей… Плохая идея — я ему уже не первый раз повторяю. Видео очень чётко и ясно даёт это понять ;-) В отместку за видео вот некоторые материалы которые я нарыл по мотивации за последнее время:

    1. www.cio.com/article/409063/Managing_and_Motivating_Developers_Tips_for_Management_Cluefulness
    2. www.giovanniasproni.com/articles/MotivationTeamworkAndAgileDevelopment.pdf
  • Emacs для начинающих: введение
    0
    извиняюсь если не правильно включил данную статью к этой теме- по сути я занимаюсь web разработкой и применяю emacs именно там (python, javascript, html, css). просто в конкретно в этой статье-введении пока про это почти ни слова. но обязательно напишу в продолжении.
  • Emacs для начинающих: введение
    +1
    > Чем он лучше других редакторов

    Если коротко — тем что предоставляет простой и понятный способ для расширения функционала, потому дополнения и модули легко дописываются желающими. Само название редактора говорит об этом (Editor MACroS). Прямо с 1х слов так и написано вот тут: en.wikipedia.org/wiki/Emacs.

    Мало того, за 20 лет написано столько всяких расширений функционала, что почти в любой сфере находиться уже готовое решение, если эта сфера хоть как то связана с редактированием текста.

    > Зачем в нём куча каких-то загадочных отдельных режимов

    Если на все файлы один режим — то ни автоподсветки ни проверки кода на корректность, ни других удобных функций редактора не будет.

    > Есть ли в нём интеграция с отладчиками (GDB, например)
    Есть. Если интересны подробности — простой поиск gdb+emacs в google даёт много ссылок и видео. я лично не пользовался — сказать ничего не могу, но отладку Python делаю в pdb, довольно удобно. Всё управляется с клавиатуры и легко копировать туда-сюда куски кода. Но подход отличается в корне от IDE отладки.

    > удобное автодополнение (в одно нажатие + автоматическое для объектов/структур)

    могу ответить конкретно по Python- функция rope-lucky-assist, выдаёт первый вариант. Чаще всего это оно. Есть варианты как показать это в командной строке/IDO, или в выпадающем меню, но однажды поняв насколько удобен ido я pull-down менюшки отключил.

    > поддержка сборки (Makefile и что-нибудь своё
    Да я обычно жму функцию compile. Если возникает ошибка — быстрый переход на номер строки. Если их много — есть функция перехода next-previous, привязанная на удобную клавишу.

    > но пока никто не отвечал
    :-) Вот стараюсь ответить.

    > Когда предлагают изучить новый инструмент, должно быть какое-то обоснование
    Те, кто работает рядом сразу видят приемущества — это конечная скорость. Т е некоторые действия, на которые в emacs есть удобно заточенные функции можно делать в другом редакторе _намного_ дольше. Ну опять же — всё зависит от человека. Даже у нас в компании, есть те, кому безразлична скорость, точнее не хочется человеку ради того чтобы раз в месяц что нибудь сделать быстро учить так много :-) А есть те, кто осваивает. Всё что стараюсь я донести — 1) то что не так страшен чёрт, как его малюют. Есть менюха, начинать работать можно с нулевым уровнем, а потом можно улучшать настройки и до-включать всякие удобные модули. 2) в этом есть смысл. Я этот смысл вижу — как по себе, так и смотря на остальных, кто смог освоить.

    Но так уж устроен человек, что ему лениво :-) Я это понимаю. Потому постараюсь в следующих статьях показать что именно я имею в виду под «скоростью» и какие фичи есть в emacs, которых не найти в самых модных IDE.

  • Emacs для начинающих: введение
    0
    Шустрее — понятие относительное. У меня как раз наоборот — Linux/GTK vim отрисовывает намного медлнее чем emacs (тест — нажать pagedown на большом файле). По открытию файлов и т п — emacs очень быстрый, т е быстрее я редактора не видел. Различия начинаются если открывать действительно большие файлы — я заметил что emacs начинает притормаживать если открыть файл 60Mb размером, у gvim таких проблем не было. Редкое дело — редактироать такие большие файлы, а запустить gvim для такой цели не проблема.
  • Emacs для начинающих: введение
    0
    Опа ;-) хоть кто то попробовал реально воспользоваться инструкцией! Извиняюсь, опечатка вышла. Закрыть файл — C-x k. Исправил в тексте. Никто не говорил что будет супер легко, особенно по сравнению с типичным редактором типа notepad2 или Kate. Но оно того стоит.
  • Emacs для начинающих: введение
    0
    > открыть текстовый файл с листингом параметрами, изменить несколько параметров и вывести
    > изменённые параметры
    вот это поподробнее. просто не понял вопроса.
  • Emacs для начинающих: введение
    0
    может программы не шибко сложные? я пользуюсь pdb (по одной кнопке ставиться через yasnippet) но он интегрирован с emacs через pdbtrack, так что код отображается по ходу нажатий клавиш. также очень удобно копировать прямо куски кода в выполняемый файл. про pdb и интеграцию с Emacs покажу на отдельном video. конечно можно было бы и лучше, я не спорю что в PyCharm отладчик на уровень приятнее, но пока хватает того что есть в emacs.
  • Emacs для начинающих: введение
    +1
    О! А можно поподробнее? Я пытался поработать в разных IDE, но по функционалу до Emacs не дотягивает, слабо подстраивается и тормозит. Если с тем, что тормозит смириться можно, но то что многие вещи приходиться тыкать мышой меня совсем не устраивают. Из IDE больше всего мне понравились для Python: PyCharm и WingIDE. Но минусы PyCharm — тормознутость и некоторая ограниченность функционала, а WingIDE слабо расширяется, обе коммерческие потому конечно и сравнивать не имеет смысла. А Eclipse как то совсем не пошёл… А в какой IDE работает автор комментария? Что именно стало продуктивнее по сравнению с emacs?
  • Emacs для начинающих: введение
    0
    Если делать сравнения по идеологии клавиатурных нажатий между emacs и vim, то наверное нет особой разницы. Что в emacs что в vim основная задача — привязать тысячи доступных функций к довольно ограниченному набору клавиш, да ещё сделать это так, чтобы это было удобно. Я думаю
    что в определённой степени оба редактора решают эту задачу, но соверненно разными способами. Я для себя заметил что мне удобнее пользоваться emacs т к _в основном_ я нахожусь в режиме редактирования при работе с текстом. Командный режим нужен реже. А кроме Vim я прошёл путь от: pe2, me, qedit, потом уже vi, vim, emacs, xemacs, kate. Смотрел на IDE: Komodo, Eclipse, WingIDE (+), PyCharm (+). Conclusion: все *java* IDE мне кажутся тормозами по сравнению с emacs, vim в то время как я им пользовался был не таким уж развесистым как сейчас, да и концепт там немного другой. Плюсики поставил IDEшкам что мне в общем понравились (в общем, не в деталях)
  • Emacs для начинающих: введение
    0
    Про плагины был вроде тут пост на хабре: habrahabr.ru/post/126228/ — советую обратиться к нему. А вообще не так уж часто я это всё настраиваю. Система у меня Gentoo, да тут не сильно важно что за система. В самой системе почти все модули, которыми я пользуюсь есть. В общем ставлю пакет и добавяю require (я отключил autoload для _всех_ пакетов т к не всё что стоит с поддержкой emacs реально мной используется).

    Хороший package manager был в xemacs, но увы, по скорости разработки и коммунити xemacs сильно отстаёт так что я им сейчас не пользуюсь.
  • Emacs для начинающих: введение
    0
    Пробовал. Впечатления двоякие. Вроде как [должно быть] проще, но только стоит привыкнуть, как приходиться переучиваться, сидя за компом у у товарища рядом. Вроде как сконвертироал пару товарищей поменять Ctrl+Alt. Но прошло вот 2 года с момента этих экспериментов, и в результате у всех как обычно, а у двух человек — перевёрнуто. Вот и думай после этого стоит ли так радикально экспериментировать. Если чисто для себя это одно дело, а если иногда приходиться работать на разных клавиатурах или в парном программировании то наверное смысла нет.
  • Emacs для начинающих: введение
    0
    Ну что сказать. Честно, картинки я никогда в Emacs не рисовал, а в сугубо практическом значении я пользуюсь таблицами в org-mode, просмотром PDF и картинок. Это очень удобно когда не надо вызывать внешнее приложение чтобы просто глянуть содержимое файла.
  • Emacs для начинающих: введение
    +1
    > вовне не копируется
    Всё копируется. Дело тут наверное в том, что в X-windows существует так называемый Primary и Secondary selection. Попробуйте сделать Paste средней кнопкой мыши. А вообще чтобы эти primary/secondary не путались у меня всегда и в KDE -> Klipper и в Parcellite стоит "[x] Synhornize Primar and Secondary Selections"
  • Emacs для начинающих: введение
    0
    Эх. Немецким spell-checker не прогнал :-) В общем исправлено, спасибо.