• Искусство программирования под Unix (и не только). Часть седьмая, «правило прозрачности»
    0
    открыл. На хабре дефолтный сабмит — в черновики. Жмешь энтер и — прощай, статья:)
  • Искусство программирования под Unix (и не только). Часть седьмая, «правило прозрачности»
    0
    Мне кажется, это вы про свой софт. А когда заглядываешь в уже сделанное кем-то ранее, удивляет, почему там иначе. Вот в продукте, который достался в прошлом году мне — иначе. Не буду оглашать компанию-разработчика, там уже из тех программеров давно никого не осталось.
  • Искусство программирования под Unix (и не только). Часть седьмая, «правило прозрачности»
    +1
    Спасибо. Как ж это хабра тогда сохранила…
  • Искусство программирования под Unix (и не только). Часть шестая, «правило кодоэкономии»
    0
    поправил :) http://raliev.ru/node/17
  • Искусство программирования под Unix (и не только). Часть шестая, «правило кодоэкономии»
    0
    Прекрасный подход :) Можно лепить из глины кусочек за кусочком, а можно — взять большое глиняное бревно и поубирать все лишнее. Отличное задание на собеседование — сделать работающий код лучше. Можно взять буквально любой модуль и отдать на трепанацию и обрезание. По крайней мере, скажет о человеке ничуть не меньше, чем модуль, заново им написанный.
  • Оптимизация ПО для iPhone: живой пример
    0
    ой, уже увидел ответ. Сорри.
  • Оптимизация ПО для iPhone: живой пример
    0
    А почему так медленно выходит iPAD-версия? Там же к разрешению мало что цепляется, по идее, должно заработать почти сразу…
  • Искусство программирования под Unix (и не только). Часть третья, «правило композиции»
    0
    Блин, он corba на cobra переправил
  • Искусство программирования под Unix (и не только). Часть третья, «правило композиции»
    0
    1. К COM претензии только в одном — за рамки мира windows он не выходит. Внутри windows вполне себе технология. Я cobra ругаю, а не com.

    2. Про узкое применение — я имел ввиду для межпрограммного взаимодействия в однородной майкрософтовской среде. Например, свою почтовую службу, работающую на юниксе, я по COM Ник чему не подключу. А по SOAP, например, вполне. Хотя, конечно, это не совсем сравниваемые вещи.

    3. Юниксовое связывание используется на несколько порядков активнее, чем виндовое COM. Потому что его используют не только 'родные' компонеты ОС, но и 90% программ на sourceforge. Поэтому с windows powershell сравнивать плохо.

    У нас тут был великолепный опыт разработки на windows script engine. я сейчас с айпада пишу — неудобно, если Макс вылезет, буду ему признателен за примеры. Это вообще чудо какое-то, а не инструмент. Хотя не совсем в тему.

  • Искусство программирования под Unix (и не только). Часть третья, «правило композиции»
    0
    я сервера имел ввиду, конечно. Если программно-аппаратное решение разрабатывается, там подход, конечно, должен учитывать требования к производительности, энергопотреблению, теплоотдаче и многому другому… Там тонкостей вообще до фига. А для сайтов-сервисов лучше добавить еще один (два, пять) сервера, зато иметь красивую и прозрачную архитектуру, чем оптимизировать донельзя, чтобы потом любое изменение было целым проектом… Я тут недавно с одними людьми общался, руководителями интернет-магазина, так у них он развернут, по его словам, на сорока серверах. Мне вообще очень сложно представить, что же там такое должно быть, чтобы не хватило 2-4 серверов. Но для 2-4 серверов написать софт, способный перерабатывать несколько миллионов хитов очень непросто. Поэтому обычно такие магазины ставят на 5-8 серверов и их достаточно по уши (у нас осенью так будет). Так вот, если есть выбор — оптимизировать ПО в ущерб архитектурной целостности и supportability, в ущерб стоимости поддержки и развития, или добавить пару серверов и ничего не трогать, то лучше выбрать второе. А трогать уже без спешки — проводить рефакторинг, взвешивая каждое изменение.
  • Искусство программирования под Unix (и не только). Часть третья, «правило композиции»
    0
    В целом — да. С другой стороны, железо стоит дешево, а люди — дорого. Лучше, когда система требует не два сервера, а пять, чем когда она быстрая и производительная, но ни один программист не может быстро ответить, можно ли в принципе реализовать какое-либо изменение, не говоря уже о том, сколько на это уйдет времени по его оценке.
  • Искусство программирования под Unix (и не только). Часть третья, «правило композиции»
    0
    Возможно, но тогда это повод пересмотреть архитектуру и сделать усложнение правильно. Без этого подхода решение простое — например, одна система просто напрямую обращается через SQL-запросы к другой. Выходит гибко-гибко. Но любое изменение структуры БД выходит очень трудоемким процессом. Если же делать через веб-интерфейсы, в какой-то момент понимаешь, что сервиса не хватает и пересматриваешь архитектуру. Это может повлечь больших затрат на проект, зато меньших — на поддержку.
  • Отдавать ли на аутсорсинг или делать самим?
    0
    Дык это я и пытаюсь сказать. Что заказывать надо либо мало, либо много. А деньги тут непоказательные. Например, в РБК СОФТ, где я работал с 2004 по 2008, нижний порог цены был от 10 (в ранние времена) до 25 тыс. (в более поздние). И это были очень несложные технически решения и проекты. Просто на них были довольно дорогие специалисты и очень отлаженный менеджмент — за это и брали деньги. А сами проекты были в подавляющем большинстве несложные. Были еще и сложные. Те стояли от $200 тыс. Но их было очень немного, зато они по характеру ближе к тому, что я называл «много».
  • Отдавать ли на аутсорсинг или делать самим?
    +1
    ключевые слова здесь «мы сделали магазин для нашего заказчика». Очевидно, что с вашей точки зрения все супер. Я допускаю даже, что клиент счастлив. Но я уверен, что если бы была возможность у клиента пойти параллельно по второму пути, в итоге он был бы успешнее. Разумеется, это не более, чем мое мнение.

    При этом я не исключаю, что на месте клиента бы принял решение обратиться к вам. Например, у меня могли бы быть сомнения, что серьезные вложения денег и времени в интернет-магазин уместны на этом этапе, а создание своей команды — это серьезные вложения, обязательства, время в конце концов требуется на организацию. Но остаюсь при своем мнении, что если хочешь хорошо в долгосрочной перспективе — делай core product своей командой.
  • Искусство программирования под Unix (и не только). Часть вторая, Ясность лучше заумности
    +3
    Не хотелось опускаться на уровень конкретных примеров. Но в будущих статьях обязательно что-нибудь придумаю
  • Искусство программирования под Unix (и не только). Часть первая, «правило модульности»
    0
    перенес.

    а в персональный и тематический — это тоже кросс-пост?

    А в ленте в новом блоге статья ж не должна по логике появиться, так как у нее дата старая? в противном случае можно каждый день туда-сюда переносить, и она всегда будет сверху. Да, вряд ли такое возможно.
  • Искусство программирования под Unix (и не только). Часть первая, «правило модульности»
    0
    перенес, действительно место ему там
    последующие статьи также будут там
  • Искусство программирования под Unix (и не только). Часть первая, «правило модульности»
    0
    Это не вполне честная логика, потому что искажается исходный посыл, после чего из искаженного посыла делаются следствия. Никто не говорил, что в мире юникс все идеально. И какой пример ни возьми — пайпы делают чудеса.

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

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

    Ну и последнее: людям свойственно ошибаться, а эволюции — тем более. В юниксе ОЧЕНЬ МНОГО того, что какой-то студент плохо продумал, а потом это «прижилось» и стало стандартом. Особенно эти страдают протоколы. Поэтому я не писал в статье нигде, что там все идеально. Но, в целом средневзвешенный мозг разработчиков юникса был отформатирован правильно и хороших примеров все-таки больше. смотреть лучше на них.
  • Искусство программирования под Unix (и не только). Часть первая, «правило модульности»
    0
    Я тут недавно, не могу в хелпе найти ответ на вопрос — могу ли я опубликовать это сразу в двух блогах? это разрешено? или тут и в персональном блоге? Как-то кажется нелогичным это делать через копи-паст.

    Дата публикации после переноса останется прежней? грубо говоря, если я статью годовой давности перенесу в новый тематический блог, она же останется столь же глубоко, что и раньше, но уже в новом?
  • Крик души: давайте писать грамотно!
    0
    Насчет второго примера спорить не буду, это уже народный фольклор. Там вообще черт ногу сломит, как писать, потому что матом преимущественно говорят, а не пишут. Но и тут авторитетные источники согласны со словарями. А пример из книги современного автора, хронического алкоголика запойного типа, как-то не канает :)
  • Крик души: давайте писать грамотно!
    –1
    вы бы хоть погуглили немного:)

    на грамоте.ру думают иначе
    толковые словари и словари синонимов русского языка думают иначе.

    Подтверждения слитному написанию не нашел нигде.
  • Крик души: давайте писать грамотно!
    +2
    Спасибо, мне очень у вас «минетжеры» понравились :)
  • Крик души: давайте писать грамотно!
    +3
    Вот уже какой раз убеждаюсь: стоит написать статью про грамматику, как ее начинают не просто читать, а выискивать недоразумения, огрехи и опечатки :) А если нашли — сразу коммент вида «первыйнах». Ни разу не было иначе! :-)