Блоґ одного кібера

Історія хвороби контуженого інформаційним вибухом

Структура деяких доповідей з ItEvent

with 12 comments

Я був на класній події в рідній Нафті. От власне мої нотатки з конференції. (Правда цінність присутності на конференції окрім доповідей полягає також і у перервах (і не в тому що під час перерви можна нахаляву нажлуктитись кави з печеньками (до речі, багато вкладених коментарів це не так страшно як Lisp. (сподіваюсь я матиму час про це розповісти ще.) ) ), але про це варто написати окремо. Вже коли вернусь в Київ. )

Я тут подумав собі – а інтелект карта – це всього лиш дерево. Принаймі Тоні Бюзен забороняв додавати цикли, бо ж заплутує. А дерево запросто записується вкладеними списками.



Якісний код

Олександр Павлишак

Як?

  • Імена
    • Осмислені
    • Константи краще ніж значення констант
    • Побільше слів Get, Fetch, Retrieve, Obtain…
    • І з предметної області
    • І робити методи з предметної області для зв’язків між сутностями. А не імена з структур даних.

  • Функції
    • Покоротше (в один екран, < 20 рядків)
    • Рівень вкладеності внутрішньої логіки < 3
    • Функція має виконувати одну функцію. Це видно зазвичай з імені.
    • Не змішувати рівні абстракції (високорівневий код в мові предметної області погано змішувати з низькорівневим (наприклад операціями з рядками))
    • Чим менше аргументів – тим краще.
    • І не повертати дані через аргументи.
    • І побічні ефекти – негарно. Особливо якщо вони не згадуються в назві.
    • Спільні дані – теж погано.
    • Функції не мають повертати інформацію про успішність виконання різних операцій. Кидайте винятки.
    • І відповідно ловіть.

  • Дублювання теж погано. Але не ціною складності. Два рази можна.
  • Видаляйте те що не використовується. Не коментуйте! СКВ вас спасе.

  • Коментарі
    • Код має бути зрозумілим, як коментарі.
    • Але якщо щось важко сказати кодом – коментуйте.
    • Коментуйте публічний API (docstring)
    • Видаляти закоментований код.

  • Класи
    • Компактні (мало відповідальностей (мало причин для зміни) )
    • Відповідно класів стане багато

  • Умовний оператор – теж погано. Трохи. Якщо його багато. Замість нього використовують поліморфізм, і інші хитрі шаблони.

  • Після проходження тестів – рефакторинг!
  • Після рефакторингу тести все одно мають проходитись. 🙂
  • Рефакторити буває так весело як і кодити. А можливо так само сумно.

СІНТ – Майстер

Ремонтують картриджі.

Всі струменеві принтери витискують фарбу бульбашкою пари, яку створює термоелемент. А Epson – п’єзоелементом.

HTML 5

Євгеній Вершинін

Фічі, фічі, фічі. Презентації є онлайн (html5rocks). Спробувати написати щось інтерактивне з svg. Він, до речі, вбудовується в сторінку.

NoSQL

Любомир Вовк

Історія:

  • 2006 Google BigTable
  • 2007 Amazon Dynamo
  • 2008 Facebook Cassandra
  • З 2009 NoSQL означає (Not only SQL)

Властивості ACID (Atomicity, Consistency, I , Durability) поганий тим, що слабо маштабується.
В 1997-99 Ерік Брюер запропонував послабити консистентність. Архітектура BASE.

Теорема CAP – в одній системі не можливо добитись одночасно консистентності, доступності, стійкості до збоїв. 2002 Сет Ґілберт, та Ненсі Лінч це довели формально. І з’явився Google, eBay, Amazon….

Типи NoSQL

  • Напівструктуровані
    • BigTable
      • Невизначена кількість колонок
      • Основна одиниця доступу до даних – клітинка
      • Кожна клітинка має кілька версій (timestamp – дата витоговлення). Дозволяє ходити по історії.
      • Фільтр Блума (Bloom filter) – імовірність знаходження ключа в файлі
      • MapReduce (Вивчити Lisp!)
      • Google: “Півсекундна затримка зменшує трафік на 20%”
  • Ключ – Значення
    • MemcacheDB
    • Redis
    • Amazon Dynamo
      • Сервери стають в коло (повне коло – всі хеш ключі). Кожен бере собі сектор цих ключів. І, якщо він вмирає, хтось що стоїть за ним, бере його сектор. Коли в стрій стає новий сервер – йому присилають дані його сектора.
      • І сталась революція. Амазон довів що BASE може приносити прибутки не менші ніж ACID.
    • Cassandra
      • Писав
    • Project Vodemort
      • Використовується в LinkedIn
  • Документоорієнтовані
    • Структуру нах!
      • JSON
      • XML
    • Представники
      • CouchDB
        • Erlang, інтерфейс REST
      • MongoDB
      • RavenDB
      • Terrastore
  • Граф-орієнтовані
    • Реалізації
      • Neo4j (Java)
      • Sones (C#)
      • InfoGrid
      • HyperGraphBD
      • vertexdb
    • Використання
      • Список друзів в соціальних мережах
      • І інші маршрути

  • Недоліки
    • Нестабільні, бо нові
    • Більша відповідальність для програміста.

  • Використання
    • Якщо є складні структури даних
    • Динамічне створення таблиць
    • Кеш/черга/лог
    • Надто багато Join-ів

Запити робляться за допомогою MapReduce (Вивчити Lisp!).

Ціна проекту

Руслан Середюк

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

Тільки 25% проектів закінчуються успішно.

Оцінка розміру:

  • Рядки коду (LOC – Lines of code)
  • Функціональні пункти (Functional points)
  • Абстрактні рейтинги (Story Points)
  • Порівняння
  • Оціночні програми

Об’єм (людиногодини):

  • Обчислення на основі розміру
  • Експертні оцінки
  • Галузеві графіки
  • Порівняння
  • Оціночні програми
Advertisements

Written by bunyk

Жовтень 24, 2010 at 15:27

Відповідей: 12

Subscribe to comments with RSS.

  1. Дуже, дуже коротко, дуже стисло… >_<

    З тезами Павлишака переважно згоден. Особливо про коди помилок в return values; повертати NULL чи None, коли від функції вимагається повноцінний об’єкт — зло, величезне never-ever-do-it ЗЛО.

    Про SVG+JS: http://ugnich.com/svg/polygons.svg

    У CouchDB HTTP інтерфейс, хоча і RESTful. Ще, CouchDB вже частково інтегрований в Ubuntu.

    ulidtko

    Жовтень 25, 2010 at 11:00

  2. Олександр Павлишак. Коментарі
    * І не повертати дані через аргументи.
    – З чого б це? Функція може вертати не одне значення, а пихати їх всі в один об’єкт не завжди є раціональним та красивим рішенням

    * Функції не мають повертати інформацію про успішність виконання різних операцій. Кидайте винятки.
    – Виключно не згоден. З таким підходом нам скоро і 4-ядерних процесорів не вистачить. Розкажу байку: try catch взагалі не жере процесор, тому можна пихати скільки завгодно їх в код. А ось throw завжди їсть, а деколи і пристойно пам’ять й процесор. Тому і існує правило – там де можна обійтись без throw, там і треба без нього обходитись.

    * Умовний оператор – теж погано. Трохи. Якщо його багато. Замість нього використовують поліморфізм, і інші хитрі шаблони.
    – Не згоден. Шаблонам місце там, де система буде активно розвиватись або у місцях, які можуть перетворитись у важкочитаємі хащі

    * Після проходження тестів – рефакторинг!
    – хех ) Розкажу, як це відбувається у нас. Код пишеться, автор його тестує. Підключає зміни в офісі, як робочу версію (!). Все вилітає, іноді навіть у всіх, автор править і знову підключає. Потім це відправляють замовникам, яких є штук 30 і всі є заводами з 200+ користувачами. У когось вилітає, автор виправляє і відсилає патч (і так робиться доки є помилки). Рефакторинг? Навіщо! Якщо працює, то не чіпай, від рефакторингу грошей багато не отримаєш. І взагалі, ми по змовчуванню пишемо одразу відрефакторений код.

    ulidtko. Коментар
    * повертати NULL чи None, коли від функції вимагається повноцінний об’єкт — зло, величезне never-ever-do-it ЗЛО.
    – Чого б це?? Постійно повертаю null, якщо створити об’єкт не вийшло! Що в цьому поганого?

    danbs

    Жовтень 25, 2010 at 22:07

    • Надавати б вам по пальцях за те що повертаєте NULL.. Переставайте писати “гавнокод”… І те що у вас програма “вилітає, іноді навіть у всіх, ” – говорить, що у вас таки “гавнокод”.

      siryc

      Жовтень 26, 2010 at 14:41

      • Автору вбивати собі в голову Clean Code. Довго сильно. Те що у вас пишуть криво “Рефакторинг? Навіщо!” не означає що так треба робити. Суть доповіді показати як пишиться система щоб її можна було читати. Ну і не забувайте відому цитату “Пишіть код наче його буде читати психопат який знає де ви живете”. Зважаючина коментарі автора.. його код без матів читає тільки він сам. Співчуваю вашим колегам.

        brut

        Жовтень 26, 2010 at 17:49

        • >>> Співчуваю вашим колегам.
          * Все не настільки погано =)

          danbst

          Жовтень 26, 2010 at 22:19

      • Дякую за відгук, проте не могли би Ви пояснити, чому null вертати погано, якщо об’єкт не вдалось створити? Що поганого в присвоєнні змінній значення функції а потім перевірці цієї змінної на null?

        Тільки конструктивно і з прикладами.

        >>> І те що у вас програма “вилітає, іноді навіть у всіх, ” – говорить, що у вас таки “гавнокод”.
        * Коли у компанії немає бюджету на виконання рефакторингу “говнокоду”, тоді планка “гівно/не гівно” дещо спадає. На мою думку, будь-який код можна відрефакторити, проте безпосередньо виконати даний етап можна тільки на невеликих проектах.

        Коли система містить більше 3 млн рядків коду, ти розумієш, що рефакторити даний код ніхто і ніколи не буде навіть при бажанню. Ти починаєш одразу писати ВІДРЕФАКТОРЕНИЙ код.

        Дякую.
        ПС. про “вилітає, іноді навіть у всіх” – хех )) тут є один нюанс. Якщо у замовника вилетіла помилка (що трапляється часто), ми оперативно її виправляємо і відсилаємо оперативний сервіс-пак (безкоштовно, звісно). У конкурентів політика інша: помилки з’являються рідше, проте якщо з’являться то компанія каже, що “даний баг буде виправлено у наступній версії” і їх не колише, що через це якийсь завод не може нормально працювати. Так що, дивіться на проблеми з усіх боків і не робіть поспішних рішень.

        Дякую ще раз.

        danbst

        Жовтень 26, 2010 at 22:15

        • Чому null – погано? Let me google it for you…..
          http://www.google.com.ua/search?q=null+considered+harmful

          siryc

          Жовтень 26, 2010 at 23:13

          • та ні, по вашому посиланню не знайшов нічого поганого про null у C#. Можливо у інших мовах все стоїть іншим боком, не сперечаюсь.

            Ви б краще привели прямо тут аргументи, і я зміг би на кожен з них відповісти.

            danbst

            Жовтень 27, 2010 at 07:57

    • Спокійно. Ви намагаєтесь сперечатись з людиною яка ніколи не обирає найпростіший шлях. Бо всі так роблять, і це вже не цікаво.

      Крім того він не завжди говорить те що думає. Інколи він говорить не те що думає щоб подіставати нормальних людей. Але в житті він нормальна людина, від якої я вперше й почув це страшне слово “рефакторинг”.

      bunyk

      Жовтень 26, 2010 at 17:59

      • сорь, але тоді це тупо тролінг

        brut

        Жовтень 26, 2010 at 18:03

        • Це не тролінг, а альтернативна думка.

          >>>Крім того він не завжди говорить те що думає. Інколи він говорить не те що думає щоб подіставати нормальних людей.
          * Влучно сказано! Я ніколи не говорю свою думку, якщо вона співпадає з поглядами більшості. Проте якщо є найменша можливість аргументованої суперечки (навіть супроти своїх “вірувань”), я нею скористаюсь. Адже “в споре рождается истина”, не знаю хто сказав.

          danbst

          Жовтень 26, 2010 at 22:23

  3. […] ItEvent цієї осені був навіть кращим ніж минулого року. […]


Залишити відповідь

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out / Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out / Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out / Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out / Змінити )

З’єднання з %s

%d блогерам подобається це: