Pull to refresh
33
0
Алексей Коваль @avkoval

User

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

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

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

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

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

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

Ну и главное — почти все решения не окончательны. Всегда можно что то попробовать, fail fast, и вернуться на правильный путь. Путём небольших экспериментов продвигаться к цели.
Хочу добавить то, что я сам пробовал поначалу по 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 минуты как работают намного лучше
Есть пересекающаяся тема по автоматизации тестирования верстки: — visual diffing tools: webdiff, dpxdt, etc.
https://www.youtube.com/watch?v=jUUTqgzNR3M с конференции по Пайтон 2015 и слайды http://bit.ly/pycon2015-visual-diffs
Очень хорошая статья, и правильно акцентирует внимание на том, что кое где автоматизацией переавтоматизировали до неадекватности. Но прошу также обратить внимание на то, что люди все разные. И кое кто предпочитает живое общение (и возможно таких больше), но меня очень сильно раздражают вот эти вот «перезвоны»: «В большинстве случаев мы позвоним (методом живой девушки из колл-центра)» — это просто сильно меня напрягает, когда ты сидишь, полностью сосредоточенный на работе, и тут, бабах, звонит полуробот получеловек ( который просто обязан зачитать тебе весь список) и начинает перечислять все товары которые я добавил в корзину. Я стоически переношу это хотя раньше пробовал жаловаться в компанию, но они этого не понимают. Не понимают что мне неинтересно слушать то, что и я так знаю. И ещё набираются наглости попытаться предолжить мне 2-3 сопутствующих товара… Как же это достало. А потом ещё возможно перезвонят и спросят доволен ли я работой оператора…
Советую присмотреться к projectile, helm. И то и другое дали очередной прирост производительности лично мне. Потом если в dired научиться пользоваться выборками/глобальными заменами вообще круто получается.
Я тут, яволь! ;-) В emacs всего хватает, если говорить о Python: есть быстрые переходы по классам, свойствам, файлам. По файлам|каталогам проекта. Автоматическое завершение ввода (3+ способами). Доступ к документации ЯП прямо из. Доступ к snippets, ну и так далее по списку. В emacs самая большая проблема наверное то, что всё вместе настроить и запомнить куда какая кнопка — нетривиальная задача, это многих отпугивает
Да. По сути — они работают в своей области более 15ти лет, перепробовали кучу ПО, решили писать своё. Как смогли нарисовали экраны и выдали нам полную спецификацию (говорили что знают всё на 100%). Но по сути, они не программисты, а продвинутые пользователи. Т е многие вещей, из за того что другие программы на аналогичную тему были не продуманы до конца, они не видели. В процессе работы предоставленные нам UI mockups сработали против проекта — так как вначале нас «нагнули» на то чтобы мы сделали «как они хотят» 1:1, а потом уже, когда к нам сформировался кредит доверия, мы постепенно вывели систему на нормальные рельсы, упростив и выбросив многие ненужные сложности. Т е на первом этапе работ, во время «сработки» были серьёзные проблемы. А сейчас всё наоборот — любые фичи и дополнения _вначале_ обсуждаются, думаем есть ли другие варианты (мозговой штурм) и потом уже принимаем совместно созданный дизайн в разработку.
Очень хорошо написано, и главное в точку. Многие описания неадекватных заказчиков — это то, с чем мне приходиться иметь дело непосредственно сейчас.

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

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


А на Wikipedia говорят

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


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

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

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

Information

Rating
Does not participate
Location
Харьковская обл., Украина
Date of birth
Registered
Activity