Хорошая идея ведь! Как думаете, откроют?
http://lenta.ru/news/2014/07/29/minkom/

Было уже может? http://www.cnews.ru/news/top/index.shtml?2014/07/25/580767

еще раз показывает, что надо использовать полностью открытые решения которые не зависят от каких либо вендоров

Дорогой ЛОР, помоги выбрать.

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

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

Написано все это дело на good old php + laravel, потестировав это дело под нагрузкой я остался не доволен, учитывая что мне потом понадобится мобильное приложение которое будет работать с API, все это дело выйдет в копеечку, да и response time как-то не очень, даже если это дело все оптимизировать я улучшу результат в 2-5 раз, но это все равно мало.

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

Под мои задачи подходят Node.js и Golang, что выбрать? что лучше? по результатам моих тестов предположительно подходят оба.

Не предлагать:
Ruby, Python - производительность будет такой же.
Java, Scala - оставьте это банкам, скорость разработки слишком низкая, IDE на Java тормозят.
C# - тут все понятно, мне он импонирует, вот только он от MS, MSVS тормозит и только под оффтопиком.
Ну и всякую другую полудохлую минорщину.

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

Перемещено mono из job

Spotify migrate 5000 servers from Debian to Ubuntu

убунту one love тред

у cloudatcost появился новый конкурент, встречаем http://www.cloudatacost.com/

вроде было несколько пользователей этого замечательного сервиса на ЛОРе.

Swift programming language уже на 16 строчке tiobe index

Пользуясь случаем хочется передать привет языкам Scala, Clojure, Haskell ну и так далее.

Знаковое событие для мира хипстерской разработки, самый большой сторонник node.js уходит из ноды в мир Go.

Профайл пациента:

ник: TJ Holowaychuk
симптомы: express, jade, mocha, koa
история болезни: https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b

Кто-нибудь сталкивался с такими ребятами на работе, если да, то чем они обычно заняты? Такие работают только в крупных конторах?

Гуглил, общая информация понятна, но интересен опыт других людей.

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

Архитектор.
Большинство руководителей обожают этот тип программистов и, действительно, любой такой деятель окажется ценным приобретением для вашей команды. В основном архитекторы концентрируются на общей структуре кода. Они мыслят объектами, а их лучший друг лист белой бумаги.

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

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

Особи, способные генерировать удачную идею в rолове (а лучше в Visio), а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Недостаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорически отказывается.

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

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

Конструктивист.

Конструктивисты получают удовольствие от процесса написания кода и его результата. Стратегическим планированием они себя утруждают не всегда, но факт в том, что с написанием кода они справляются быстро, причем в большинстве случаев ошибок в нем не обнаруживается даже на этапе альфа-тестирования.

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

Впрочем, если на него немного надавить и дать понять, что без документции никуда не деться, он, вероятно, согласится ее составить - и сделает это качественно. Кто спорит - код должен быть самодокументируемым, но следует иметь в виду, что основное внимание программисты этого типа уделяют процессу создания кода, поэтому остальное для них не так уж важно. Количество сборок, которое конструктивист выдает за день, позавидует даже Microsoft.

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

Художник.

На самом деле, искусства в написнии кода не меньше, чем науки, не зря же университеты часто сводят оба направления в одной структуре и называют ее как-нибудь вроде «факультета свободных искусств и наук».

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

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

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

Инженер.

Эти ребята имеют обыкновение скупать все возможные средства сторонних производителей, писать десятки COM-объектов и сводить их воедино, так что они прекрасно работают в версии 1.0, присущая им тяга к усложнению проявляется лишь тогда, когда речь заходит о версии 1.1.

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

Ученый.

Ученые - это мальчики и девочки, которые считают себя последователям Бэббиджа и Тьюринга. Никогда в жизни они не вставят в код инструкцию GoTo. Отодвигая художественную составляющая программирования на второй план, они делают все в соответствии с фундаментальными принципами компьютерных наук.

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

Программисты такого типа на самом деле очень полезны, и когда речь заходит об особо трудных задачах кодирования, их идеям нет цены. Нужно следить за тем, что бы их педантичность не перевесила практические соображения. У инженеров и ученых есть одна общая черта - и те и другие любят все усложнять.

Лихач.

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

Волшебник.

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

Более того - волшебники делают все это вовремя, и иногда у них получаются вполне доступные для понимания программы, которые можно сопровождать.

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

Минималист.

Несмотря не удивительно скромный объем кода, производимого минималистами, код обычно оказывается очень функциональным. Каждая процедура умещается в редакторе кода на одном экране. Объекты стройны, выстроены четко и недвусмысленно сообщают о своем назначении.

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

Иногда минималисты капризны и очень придирчиво выбирают область приложения своих сил. С сопровождением кода дела у них обстоят хуже всех.

Аналогист.

Это программист, который не слишком силен в абстракциях, но прекрасно справляется с аналогиями. Во время проектных совещаний аналогисты постоянно выдумывающие все новые и новые аналогии, способны свести с ума любого.

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

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

Трюкач.

Трюкачи слишком увлекаются разными технологическими трюками. Они постоянно осваивают разные новинки, но результат от этого не улучшается. Трюкачи, при всех их познаниях в технологии, часто не могут усвоить конечное назначение программы.

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

Разгильдяй.

Они не обращают внимания на такие мелочи, как правильно написание имен переменных и правила венгерской нотации. Зачастую качественно выполнять свои обязанности им мешают проблемы личного плана.

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

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

Тормоз.

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

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

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

Любитель.

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

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

Они отказываются признавать превосходство ООП над процедурной парадигмой - и все потому, что нужное прозрение их еще не посетило.

Профан.

Это тот, кого называют тупицей. Хуже все, когда профан не догадывается о своей тупости. Остерегайтесь таких людей. Иногда они могут достаться вам в наследство от предыдущих руководителей, но сами я вас прошу, никогда их не нанимайте. Если человек невежда, но хочет стать лучше, - дайте ему шанс. Отправьте его например в отдел тестирования.

Эклектик.

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

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

Ковбои.

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

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

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

А кто вы? :D

Нужно/ненужно?
трубки делают нас рабами?
Отвечаете ли на звонки когда на работе?
Отвечаете ли вы на звонки когда занимаетесь чем-то важным для себя? (сайд проект какой то или типа того)
Сколько раз в день вам звонят?
Сколько минут/часов в день уходит на бесполезные разговоры?
А на полезные?
Сильно ли сотовая связи ломает контекст того, чем вы были заняты сейчас (если были?)

не соц. опрос если что, просто действительно интересно, меня сотовая связь крайне раздражает например, всем что-то надо, мне же ничего не надо :)

На javascript то оказывается уже куча-куча десктоп приложений вполне сносного качества и они даже кроссплатформены благодаря webkit

на asm.js скоро уже будет писаться все, правда автор прогнозирует его смерть из-за этого

а вам страшно по ночам из-за javascript и будущего которое он нам несет?

Игра в которую наверное стоит поиграть каждому :)

http://store.steampowered.com/app/238210/

Прославленный герой Джулиан Ассанж как бы намекает

Знаю были потуги пару лет назад, потом этой темой сильно не интересовался, в Qt 5.2 вроде бы добавили возможность полноценно делать приложения для Android/iOs - однако добавить это не значит сделать нормальный, полноценный юзабельный продукт. Поэтому есть ряд вопросов для практикующих (если такие есть).

1. Qt 5.2 использует нативный интерфейс на Android/iOs или тащит свой? Если свой - то насколько убого он выглядит и точно ли он пройдет те же гайдлайны для размещения в App store например (учитывая как они любят все выпиливать) ?

2. Есть какие-то известные приложения в обоих магазинах приложений которые можно потыкать/посмотреть на конечный результат и стоит ли оно того

3. Есть какие-то серьезные косяки или проблемы о которым стоит знать изначально?

Что же, видимо эра PHP в фейсбуке подходит к концу, вначале форкнули рантайм и теперь сидят на HHVM, теперь вот планомерно вытравливают PHP из всего кода фейсбука

Чем отличается от PHP и зачем нужен: PHP объявлен legacy для Facebook и весь код портируется на Hack, «почти» полностью совместим с PHP, но имеет кучу плюшек:
- type annotations
- Generics
- Nullable Types
- Collections
- Lambdas
- Shapes
- Type Aliasing
- async/wait
- more to come..

Hack: a new programming language for HHVM
hack language website
много информации можно почерпнуть из ответов разработчиков языка на hacker news

сам лично считаю, что шаг в определенной степени полезен для Facebook, но Hack навряд ли получит какое-то распространение за его пределами, по крайней мере пока Hack+HHVM не ускорят раз в 50 так за счет типизированности, но даже если и так, то зачем тут уже PHP? Берем Java/Scala/C#/Whatever и вперед

Вариантов деплоя рельс как-то слишком много, непривычно.

В гугле везде метрики в основном rseq, но почему-то memory consumption (важный пункт) почти везде опускают, интересует личный опыт лоровцев по таким пунктам у каждого сервера как:

1) проблемность, стабильность (баги или еще что)
2) потребление памяти (меньше лучше)
3) геморойность деплоя
4) время старта
5) производительность

Пока использовал только Thin, вроде туп и прост, это плохой или хороший выбор? почему?

Почему пишут, что Unicorn только для fast clients, что он не так сделает с остальными? как Rainbows решает эту проблему?

Puma это cutting-edge убийца всех остальных серверов ? Или его место у помойки???

Появилось немного свободного времени, подумал поконкретнее изучить Ruby вместе с рельсами для производства всякой мелкой/средней нетривиальщины от заказчиков, а то от пхп фреймворков устал, а питон с джангой с которым я закрыл пару проектов как-то меня не __улыбают__, не лежит душа.

Но вот есть еще модная Scala вроде как, библиотек всяких заимствовать из явы можно много, в тренде и веселья полный дом.

Может ее? пугает только постоянная отсылка к Java библиотекам, придется рано или поздно их читать хотя бы, похожая история с coffeescript/javascript, где я в итоге сдался и вернулся к старому доброму уродливому javascript, а то написание в одном и дебаг в другом (да и все библиотеки на яваскрипте) это ужас

Как там с фреймворками на Scala? что-то типа рельс есть? Play Framework читал вбросы шаблоны компилит по минуте после каждого исправления или это вранье?

Scala это только для парней из ява-мира или это миф?

p.s. важный фактор это скорость разработки, если не самый важный :)

Перемещено mono из talks

Интересна стратегия подхода к подобной задаче.

Дано: допустим навскидку 50000 rows (может быть сильно больше) в какой-нибудь RDBS в каждом row есть поле с текстом с 2000-6000 символов.

Надо: найти дубли которые будут либо полностью идентичны либо close enough (отличие в слово или несколько символов с подобным же порядком остальных слов), здесь вариаций может быть очень много, НО будем придерживаться более-менее простой модели.

Как бы вы решили эту проблему? очевидно выбирать каждый row и по некому алгоритму типа levenshtein distance сравнивать с 49999 rows будет не очень эффективно и как-то тупо :)

Есть как бы алгоритм шинглов, поидее можно построить некий внешний индекс выбирая в task queue все ячейки раз в день/ночью и потом уже сравнивать намного более короткие версии этих текстов на наличие почти-дублей, но мне всеравно это кажется как-то затратно, может есть идеи получше?

Дано: VPS, пара говносайтов на php которые работают на apache+nginx(статика).

Что надо: запихнуть туда еще один говносайт, но уже на rails. Какие варианты деплоя использовать, что бы использовалась та же связка из apache+nginx(статика), ближайшее что нагуглил это phusion passenger, вроде как работает схожим образом встраивая mod_что-то в апач - в верную сторону смотрю или есть варианты получше?