• Начать изучать теорию программирования прежде чем лезть в языки?

    Кнут хорош именно как фундамент. Насчет «новшеств» --- Вы всего Кнута имеете ввиду, или только его «классику» в 3 томах? Если все, то что именно он не включил в базу?

  • Начать изучать теорию программирования прежде чем лезть в языки?

    Лучше Кнута все равно пока ничего не придумали...

  • Предложение университетам

    Недавно на ЛОРе отрыл статью в темуhttp://www.rsdn.ru/article/car...Самый пикантный момент тут в том, что пишет это профессор американского ВУЗа. Получается, что и их система сбоит.> Брукс в пресловутой книге «Мифический Человеко-Месяц» пишет что он 20 лет преподает computer science, где студентам предлается в составе групп 3−4 человек реализовать некий реальный продукт.Можно еще вспомнить «Этюды для программистов» Чарльза Уэзерелла. В этой книге собраны «программистские этюды» — достаточно сложные в практическом исполнении учебные задачи, которые, однако, не требуют столь серьезной и напряженной работы, как реальные проекты.Ведь основная сложность тут в том, что при обучении решаются немного не те задачи, что при разработке реальных приложений. Тут рулит принцип «repetitio est mater studiorum», посему задания для студентов должны быть достаточно однотипными и в меру повторяющимися. Кстати, об этом говорили на последней OSDN-овке с одним преподавателем из Львова. Занятный получился разговор.То, о чем написал Брукс, вполне укладывается в систему студенческих дипломных работ.IMHO, единственное, о чем есть смысл обеспокоиться серьезно, так это об обучении студентов работать в команде. Отсутствие таких навыков серьезно напрягает, когда студент приходит в реальную компанию. Ну, а все остальное прикладывается.

  • Ubuntu Linux на HP nx7010

    > Из существенных проблем — «засыпание» (apmsleep suspend) не работаетМожет, потому, что apm? Лично я свою тамагочу так и не научился усыплять. Правда, там еще ядро 2.4.> В Firefox и vim (vim!) не работают горячие клавиши в русской раскладке. Недавно на ЛОР пробегал плагин для FireFox, который фиксит проблему с раскладками. Автор уже удалил файл, но я своевременно скачал его и размещаю тут: http://aroks.kiev.ua/kev/files...Для vim проблема остается. Впрочем, как и для emacs

  • OSDN’06 Киев — отчет

    > Мне запомнились доклады студентки ДонНТУ о программе Google SoC и разработчика LiveCD дистрибутива Frenzy.Как ни странно, мне тоже. Я даже пришел вечером, скачал его и слегка поигрался. Правда, сеть в нем так и не поднялась: — (.> Доклад лучше не делать сразу после перерыва — многие слушатели продолжают подтягиваться во время выступления.От себя добавлю: и сразу перед перерывом тоже. Во-первых, могут быть проблемы из-за регламента, а во-вторых, очень большой соблазн сорваться в буфет, пока там не образовалась очередь.Кстати, с туалетами положение тоже было отвратительное. Странно, три года назад такого не наблюдалось...> Как по мне, восьмичасовой линейный формат выступлений не очень удобен. Я бы предпочел 5-часовую конференцию с двумя параллельными сессиями, чтобы можно было выбрать более для себя интересную.Если учесть, что в начале сентября было заявлено только пять докладов, то на сессию просто не набиралось. Я так понял, для организаторов 27 докладов само стало неожиданностью. В общем, похоже, это просто проблема роста — трудно заранее предсказать, сколько будет докладов.

  • OSDN’06 Киев — отчет

    > на самом деле если с помещением проблема, то может быть стоит исп. временное разделение — утром для разработчиков, вечером — для админов и юзеров (предпочитаю объединять эти две категории в одну — пользователи).А смысл заменять настоящий параллелизм псевдопараллельными моделями? Времени все-равно столько же уйдет.

  • OSDN’06 Киев — отчет

    > По моєму, доповіді про Ідеальну країну та rootUA нікуди не годяться, хоча в жодному випадку не бажаю образити доповідачів.Не забывайте, что оба докладчика выступали на этой конференции в первый раз; -).Что касаемо меня, то сам понимаю, что доклад скомкал. Ибо вначале пришлось ужимать выступление до пяти минут, а затем после неожиданного переноса дали все 15. Понятно, что треть этого времени я так и не использовал, а сам план пришлось перестраивать на ходу. Вот и получилось путано. Однако, судя по обсуждению в кулуарах, тема таки вызвала интерес. Поэтому считаю, что цель была достигнута.Что же касается root@ua, так они и так сами за себя скажут. По крайней мере, публикацией полной версии наших докладов.

  • Взгляды на интерфейсы (типа 50 тезисов)

    Да, 23 дюйма — это даже больше, чем на моем телевизоре... На такое можно смотреть только с 3−5 метров — на диване, с дистанционной клавиатурой и мышью. Естессно, при соответствующем масштабе шрифтов и пиктограмм.Другой вариант — откройте все мыслимые панели, которыми так пестрят нынешние офисные приложения (например, http://www.3dluvr.com/amigo/fu..., http://blogs.netindonesia.net/..., http://www.filejournal.com/ass...). Будет самое оно: -).Наконец, всегда есть возможность «плиточного» расположения окон. Чаще всего я пользуюсь этим в VIM или Emacs, но там все-равно больше трех-четырех окон не открыть, а иногда и двух уже много. Но причина другая — окна становятся слишком маленькими.

  • Weekly linkdump #43

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

  • MySQL rant

    Года три назад я проводил сравнительное тестирование производительности СУБД на основе некого теста. Собственно, вначале сравнивались PG (версии 7) и BDB, как типичные представители SQL-сервера и навигационной базы. Навскидку проигрыш SQL был примерно в 10 раз. Отсюда делался вывод, что SQL проще в разработке и надежнее, но проигрывает в эффективности.Потом уже чисто для себя решил прогнать через тот же тест MySQL, и оказалось, что быстродействие его сравнимо с BDB. Позже я узнал, что, собственно, само хранилище MySQL построено на движке BDB, отсюда и неудивительные результаты.Однако, в последнее время (в версиях 4 и 5) MySQL вводит альтернативные хранилища, в частности, на InnoDB. Это хранилище позволяет все упомянутое: и ссылочную целостность и транзакции. Производительность на этом движке я не проверял (равно, как и PG версии 8), однако подозреваю, что она будет заметно ниже — как-никак, бесплатных пирожных не бывает. Если интересно, могу как-нибудь попробовать.В общем, важно то, что MySQL дает возможность выбора: можешь сделать быстро и ненадежно, а можешь сделать медленно и надежно.Насчет «выдает неправильный ответ» в MySQL при переходе от тройки к четверке было замечено изменение правил округления, что сгоряча объявили багой. Однако, оказалось, что это наоборот, фича, связанная с переходом на SQL-92 в версии 4. Так что, «не считать приоритетным» и «не делать вообще» — несколько разные вещи. Кстати, представления в MySQL сделаны по одной единственной причине: не нужны. В доке прямо написано — будут сделаны, как только найдутся желающие профинансировать разработку этой фичи. Видимо, желающих профинансировать пока не нашлось.Насчет «падает база». Что в PG что MySQL мне ни разу не пришлось восстанавливаться. Единственный мой опыт перестройки индексов в MySQL был связан исключительно с переходом от версии 4 к версии 5.Насчет «навороченности PG». В версии 7 меня очень привлекала фича «наследования таблиц», что позволяет использовать ООМ при разработке модели данных. Поговаривают, что такая фича есть в Oracle (хотя, наверное, проще перечислить, чего в нем нет), но ее использование тормозится тем, что все оригинальные фичи Oracle имеют особенность работать раком в самых неожиданных ситуациях.

  • MySQL rant

    И еще, в пользу PG могу упомянуть EnterpriseDB — открытую СУБД на основе Postgres, мимикрирующую под Oracle. То есть, возможно начать разработку на PG, а по мере появления финансовых возможностей мигрировать на Oracle. Правда, сколько нужно пилить напильником при миграции, я не знаю. Не исключено, что выгода не такая уж и серьезная.

  • MySQL rant

    Издание «C’T magazine» провел соревнование среди наиболее популярных open source СУБД. В качестве теста было предложено обслуживание клиентов в интернет-магазине.Результаты участников: MySQL5/PHP: 3664 заказов в минутуDB2/Java: 1537Oracle/Java: 1412PostgreSQL/PHP: 120http://www.mysqlperformanceblo.../

  • MySQL rant

    PostgreSQL сложнее, её нужно уметь оптимизировать и уметь правильно строить базы данных.

    "Вы не любите кошек? Вы просто не умеете их готовить! «Вообще говоря, это называется «жертвовать скоростью разработки и стоимостью поддержки».Так что, это опять же банальный вопрос выбора: что важнее — стоимость сопровождения и производительность с одной стороны или высокая надежность — с другой.

  • MySQL rant

    Кстати, из обсуждение вышеприведенного бенчмарка на ЛОРе:

    Я, кстати, делал сравнение производительности MySQL и PostgreSQL, так вот, производительность в тестах различалась не более чем на 10 — 15%, причем в обе стороны.О чем говорят результаты моего теста? Да ни о чем! Потому, что это были моиусловия_эксплуатации_ в моем проекте. В других проектах может выиграть MySQL — там, где мало таблиц и почти нет связей между ними. Может выиграть и Постгрес — там, где надо держать бизнес-логику в базе, а не снаружи

    Так что, пора завязывать с этими священными войнами...

  • MySQL rant

    Еще не стоит забывать, что mysql блокировщик в то время как pg и oracle версионники. На разных задачах — разные плюсы и минусы.

  • MySQL rant

    В общем, для тех, кто желает отдохнуть душой: http://www.linux.org.ru/view-m...Кстати, по поводу постгрессовских ANALYZE и PREPARE — они вполне могут спасти ситуацию. Может, таки проведем еще один забег, но с полноценным тюнингом от фанатов соответствующих СУБД? В рамках MySQL-PG-Orackle? Кто берется помочь?

  • MySQL rant

    Впрочем, не в первый раз. Одно время Макс пытался пройтись по больной мозоли vim vs emacs, но меня тогда не зацепило. И еще много таких тем есть. Правда, при всем при том ЛОР в подобных вопросах вне конкуренции: -).

  • MySQL rant

  • Метод BigBook для менеджера проектов

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

  • Метод BigBook для менеджера проектов

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

← Сtrl 12 Ctrl →