Sannis

Молоток vs Кувалда vs Отвёртка

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

Результат: если ударить больно, то палец болит. В чём же тогда прелесть отвёртки? Понимаю, что она подходит для узконаправленных задач, например, только откручивание или закручивание, т.е. для ограниченных задач. В остальном одни минусы: и держать неудобно, и площадь поражения невелика, и по пальцу я попал только с третьего раза.

PS: Что вы используете для надёжного перманентного отбивания пальцев? Холивар классический русский молоток vs молоток из икеи можно опустить, разницы между ними практически не будет.

Помимо РСУБД, мы используем MongoDB. Замечательная и быстрая штука, которая позволяет хранить коллекции из деревьев любой формы, строить индексы по любым их узлам, легко масштабируется горизонтально, имеет довольно мощную систему запросов на чтение и обновление. Недостаток — отсутствие джойнов, проблемы с агрегацией, они решаются путём предварительной агрегации при изменении данных или переучётом по крону.

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

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

Если много мелких файлов, то ReiserFS.

Или например у нас много мелких медиафайлов (музыка, фото) и много клиентов, тогда для нас существенным фактором будет являться фрагментирование, а не ФС.

Но тут ещё надо помнить, что в линуксе (да и не только) файлы кешируются, и если оперативы достаточно, то какая файловая система будет уже не важно.

В общем я думаю, что в каждом конкретном случае надо подбирать.
Также я думаю, что если вы не работник ДатаЦентра Гугла, то вам не стоит заморачиваться именно на файловом системе. Ибо прирост врядли составит более 20%. А вот заморочится на физических характеристиках HDD, рейде и оперативной памяти как раз таки стоит.

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

Практика показала, если возникают такие вопросы, писать на Руби или ПХП, то пишите на ПХП.

> как php превратить в приятный для самолюбия язык?
Взять MVC фреймворк на php. И получить и AR, и MVC, и какой-нить шаблонизатор, если хочется коротких тегов.
А то вы сравниваете Rails и PHP, т.е. фреймворк и язык, и удивляетесь, что в PHP нет AR. =)
В чистом Ruby, тоже нет ведь перечисленного вами…

К тому же, я не профи в Ruby, но что-то не верю, что нет гемов для работы с почтой.

>Подскажите, как это происходит без заголовочного файла?

Когда компилятор делает .o файлы, там название функции next будет без манглинга, то есть просто _next
И когда ld (он же линкер) собирает из двух .o в один исполняемый файл то будет всё Ок.

А если делать на С++ (он же g++) этот фокус не пройдет, потому что там будет манглинг имен и в одном .o файле получится типа _next@gcvd а в другом _next@vdsf и линкер это не соберёт. Хотя на С++, похоже, компилятор тоже ругнется, что встретил девушку полумесяцем бровь функцию без заголовка.

Объявление функции необязательно. В таком случае компилятор подразумевает, что функция имеет любое количество аргументов и возвращает int. Прототип: int func();
В процессе линковки функция нашлась в next.o, а значит всё хорошо %)

Меня укусил комар, нога страшно чешется. Подскажите, как правильно отрезать ногу?

Особенности национальных форумов: в америке ответят, в европе пошлют, а в россии объяснят, почему ты дурак (анекдот). К чему это?
Не надо мне предлагать перетерпеть это. Нога безумно чешется, потому её надо именно отрезать.

Пользовался (и пользуюсь, на разных проектах) и SVN и git, первым уже давно, вторым около года. Если есть возможность выбора — всегда выберу git, независимо от числа разработчиков, в первую очередь за удобство branch\merge, за быстроту (поскольку весь репозиторий локально) и за другие преимущества, о которых уже много написано. На мой взгляд, если поймешь git, то по своей воле к SVN уже не вернешься. Но это с точки зрения разработчика.
P.S: в git папка .git только в корне, а у SVN — в каждой папке.

Имхо, если разрабов не больше десяти и не со всего света, то svn предпочтительнее, тем более, если svn уже юзается

эту тему уже затёрли, не поленитесь и сходите в гугл, ничего нового вам не напишут.

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

Кстати, в режиме паранойи, Raid 5 лично мне не добавляет уверенности, по опыту — весьма проблемный вариант при восстановлении, стоит рассмотреть вариант с двумя зеркалами или десяткой.

Mac известного фаната Apple (Wylsacom)

Про pycharm не скажу, но функционал IDEA и phpstorm в плане пхп одинаковый.
Разница в том, что в IDEA уйма лишнего фукнционала, который совершенно не нужен и захламляет интерфейс. А еще она памяти больше кушает.

Но, я думаю то, что использование одной IDE удобнее, чем двух, перекроет эти недостатки.

LaTeX + Beamer.

Как проходит собеседование с верстальщиками, какие тестовые задания? Уровни отбора? Где хедхантят верстальщиков?

Как пишите внутренние спеки по кодстайлу? Как организуете статичны HTML шаблоны?

Эти вопросто не только к яндексам, если вы тоже поделитесь своим опытом, будут благодарен.

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

> Какова «максимальная» должность, работая на которой решать нужно только технические вопросы

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