• Где найти генеалогическое древо UNIX-подобных систем?

    @S1ashka
    www.levenez.com/unix/ чего уж там
    Ответ написан
    Комментировать
  • Помогите отладить автоконвертер видео на bash плиз

    @egorinsk
    Bash-скрипт в 99% случаев должен начинаться с set -e. Странно, что никто не замечает таких вопиющих ошибок.
    Ответ написан
    Комментировать
  • Mutable или T* const?

    ixSci
    @ixSci
    Если константность Вам досталась по наследству и Вы не можете этого изменить, то выбирайте любой вариант и не надо слушать всяких снобов о «некрасивости, неэтичности» и прочем. Все эти «неэтичные» средства в языке, как раз и созданы для того, чтобы обрабатывать нестандартные ситуации.
    Если по теме, то я бы выбрал mutable.
    К примеру, для того, чтобы сделать getItem для потоко-безопасного, разделяемого контейнера может потребоваться использование mutex.lock(). При этом, getItem семантически является константным, и должен быть объявлен как getItem const; но чтобы лочить mutex в этом методе, необходимо его изменение. Где бы Вы не встретили решение подобной проблемы, бьюсь об заклад, что mutex будет объявлен как mutable поле класса.
    Ответ написан
    Комментировать
  • За что разработчик может уважать менеджера?

    80x86
    @80x86
    За то, что это — образ жизни.

    Я попробую изложить тут свой опыт. Думаю, получится ОЧЕНЬ субъективно. Увы.

    Последние три года мне приходится быть этаким Jack Of All Trades (к счастью, без продолжения “master of none“). Я начальник отдела автоматизации учебного процесса довольно большого, но весьма вялого до этой самой автоматизации ВУЗа. Жизнь сложилась так, что кроме этого я занимаюсь веб-разработкой (скорее фрилансом) и координацией нескольких полузакрытых проектов, выросших из аутсорса.

    Соответственно, приходится заниматься административной работой, организационно-координационной и непосредственно разработческой. И рисовать, верстать, копирайтить, тестировать, составлять матмодели, заниматься статистической обработкой и немного паять.

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

    До этого, примерно лет пять назад, когда я был чистым разработчиком, на работу менеджеров проекта/команды (да чего уж кривить душой — и на работу любого административного работника) смотрел с презрением, граничащим с этаким public riot. Скорее всего, мне просто не попадалось действительно хороших ПМов, которые бы умели поставить рабочий процесс так, чтобы разработчик понял, что о нём заботятся.

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

    Ещё мне дико не нравилось решать задачу некрасиво, причём это часто выражалось в затягивании сроков. Если мне начальник говорил:

    — Надо срочно сдать! Хватит тянуть резину, что у тебя там, почему нельзя сделать быстрее?

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

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

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

    А потом я стал начальником.

    Начальником болота, где не слышали про VCS, например. Вообще. И про проектирование.

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

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

    С тех пор многое поменялось в голове: я научился жертвовать перфекционизмом в пользу выполнения поставленной задачи; научился делегировать работу; научился избавлять разработчиков от головной боли и смятений в выборе способа решения задач, выполняя роль своеобразной бритвы Оккама; научился… да научился много чему.

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

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

    Слава святому фон Нейману, такие люди, оказывается, есть и их достаточно много. В сравнении себя со многими из них я понимаю, что мне есть, куда стремиться. И это потихоньку топит лёд моего внутреннего разработчика, который потихоньку учится уважать менеджеров.
    Ответ написан
    Комментировать
  • За что разработчик может уважать менеджера?

    Stdit
    @Stdit
    За то, что он снимает с меня обременительную задачу общения с заказчиком напрямую.
    За то, что он понимает и грамотно описывает желания заказчика, после имплементации которых последний получает именно то, что хотел.
    За то, что он правильно расставляет этапы и знает цену хотелкам-переделкам, особенно после утверждения заказа.
    За то, что создаёт комфортные и приятные условия работы (мебель, воздух, чистота, шумоизоляция и т.д.).
    Вообще, за то, что он понимает, зачем он нужен и как его работа повышает стоимость часа. И делает это, а не чатится в социальных сетях.
    Ответ написан
    1 комментарий
  • Winapi LoadLibrary: как узнать недостающие символы?

    volodymyr
    @volodymyr
    LoadLibrary(MSDN LoadLibrary) только загружает DLL в память.Если вернулся NULL — скорее всего библиотека не найдена. Для получения адреса функции следует использовать GetProcAddress(MSDN GetProcAddress)
    Ответ написан
    Комментировать
  • Разработка Unix-приложений?

    tamerlan311
    @tamerlan311
    QT абстрагирует программиста от особенностей операционной системы практически полностью, собственно для этого она и разрабатывалась.

    Когда в резюме указывают «Unix программист» я думаю что подразумевается человек, имеющий представления об основных технологиях, используемых в unix-like системах. Это прежде всего представление о том что такое POSIX, Стандарт иерархии файловой системы ru.wikipedia.org/wiki/FHS, основы bash-скриптинга. И еще много мелочей которые способны сильно облегчить жизнь и сделать архитектуру приложения проще и элегантнее.
    Ответ написан
    Комментировать
  • Какой лучше купить или сделать компьютерный стол?

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

    Поэтому советую вам купить обычный письменный прямоугольный стол, размеры под ваши нужды (напр. у меня 180x80, но сейчас думаю что лучше бы взял 160 по ширине)
    Ответ написан
    4 комментария
  • Не компилируется helloworld.cpp в g++

    @gribozavr
    Если у вас старый и несовместимый со стандартом целевой компилятор — то на нём и разрабатывайте, а то кроме этого вполне очевидного глюка получите ещё десяток неочевидных.
    Ответ написан
    1 комментарий
  • Помогите выбрать WIFI-роутер

    liveder
    @liveder
    а официальный от Apple тогда чем не нравится? =)
    Ответ написан
    1 комментарий
  • Как лучше всего перевести на русский язык слово thunk?

    lashtal
    @lashtal
    thunk — преобразователь

    A small section of code that performs a translation or conversion during a call or indirection. For example, a thunk is used to change the size or type of function parameters when calling between 16-bit and 32-bit code.
    www.microsoft.com/Language/en-US/Search.aspx?sString=thunk&langID=ru-ru

    Перевод тут однозначный, используйте его. По ссылке еще примеры использования.
    Ответ написан
    1 комментарий
  • В какой город переехать?

    @ArturSitnikoff
    Служба заботы о пользователях Internet
    Удалено через 3 года за ненадобностью инфы
    Ответ написан
    7 комментариев
  • Как стать программистом?

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

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

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

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

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

    Stdit
    @Stdit
    Чтобы стать программистом, который не просто пишет по гайдлайнам, но ещё и всё понимает и чувствует код, надо написать не один десяток велосипедов и сравнить свои велосипеды с велосипедами других программистов. Понять, почему твой велосипед работает хуже и написать новый велосипед.

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

    Конечно, я не одобряю велосипеды в профессиональном программировании, но для обучения и саморазвития, по-моему, нет ничего лучше.
    Ответ написан
    1 комментарий
  • Бесполезный вопрос nix shell

    Evengard
    @Evengard
    tiswww.case.edu/php/chet/bash/FAQ

    E10) Why does 'cd //' leave $PWD as '//'?

    POSIX.2, in its description of 'cd', says that three or more leading slashes may be replaced with a single slash when canonicalizing the current working directory.

    This is, I presume, for historical compatibility. Certain versions of Unix, and early network file systems, used paths of the form //hostname/path to access 'path' on server 'hostname'.
    Ответ написан
    2 комментария
  • Замена notepad ++?

    cypok
    @cypok
    Ну тогда уж и Vim гляньте :)
    Turn Vim into Powerful JavaScript Editor
    Ответ написан
    Комментировать
  • Замена notepad ++?

    @Chii
    Ответ написан
    Комментировать
  • Apple Mac Mini для разработки игр?

    DevMan
    @DevMan
    Поменять память на 8Гб и HDD на получше или SSD (родные диски весьма тормознутые) — летать будет.
    Ответ написан
    Комментировать
  • Безобразно работают Bluetooth-наушники (apt-x) на Mac. Что делать?

    @YoungSkipper
    У меня Sennheiser PXC 360 BT + Macbook Air Lion
    1. Проблем с качеством звука нет
    2. Если уйти на короткое время из зоны доступа <1 шт — сначала помехи, потом замолкает, возвращаесь — опять сначала помещи, потом все ок
    3. Если уйти на большее веремя, то при возвращении звук не востанавливаетмся. На компе диалог «Произошла ошибка аудиоустройства Bluetooth.» с одни выбором «Не использовать наушники»
    4. Если потом выбрать наушники в BT меню и сказать использовать как аудио устройство — то все ок.
    5. Но если в течении этого времени телефон например приконнектиться к ним — то просто использовать не получится. Наушники нужно перегрузить в режим спаривания, еще раз сделать подключение к компу.
    Ответ написан
    Комментировать