GrAndSE's blog

З днем системного адміністратора

Ну що ж, от і настав день свята, з яким би я хотів привітати всіх, хто може носити це горде звання. Хочу побажати їм гарної заробітної платні, ПЗ без помилок, адекватних користувачів та співробітників, цікавої і водночас спокійної роботи ну і звичайно ж здоров'я та щастя. Як би там не було, однак без гарних системних адміністраторів ні програмістам, не користувачам комфортного життя не буде, оскільки кожен має займатись своєю справою. Так що ще раз Вас вітаю зі святом Систсемні Адміністратори.

Погляд на Mac OS X

Вже більше тижня минуло з того дня, як почав своє близьке знайомство з Хакінтошем (так-так і я туди). Для експериметів було обрано збірку Kolyway Leopard та доволі слабеньку машіну на основі Intel Atom. І от вирішив поділитись своїми враженнями, отриманими в процесі роботи з системою.

Скажу одразу, що враження досить неоднозначне. З одного боку цікава система, зі своїми особливостями та перевагами. А з іншого боку, я очікував чогось більшого, чогось такого, що б захоплювало, закохувало. Однак щось не вийшло.

Але всьому своя черга.

Пам'ять і розум

Кожному щодня доводиться вирішувати певні завдання. Хоча б приймати рішення стосовно свого ранкового чи обіднього меню. Звичайно, що для вирішення такого складного завдання, як аналіз факторів, що впливають на формування щоденного раціону окремої особи, треба розглядати соціальні, економічні, політичні, екологічнї, психологічні фактори та ще й приймати до уваги смакові вподобання конкретної особи :) Цим я займатись не буду. А поговорити я б хотів сьогодні про роль пам'яті у процесі мислення взагалі та написанні програмного коду.

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

Наскільки щвидко працює Java Reflection API

Моя попередня замітка присвячена викорисатанню Java Reflection API. На основі цієї технології працює багато фішок мови Java. Наприклад Serialization та Enterprise Java Beans. Фактично всі вони полегшують дуже сильно життя розробнику ПО з використанням Java. Однак, вже доволі давно я прочитав в Developing without EJB про те, що все що базується на основі цієї технології працює не дуже швидко. Тести я дуже люблю, тому вирішив перевірити, наскільки це твердження правдиве. А незодавно в мене з'явилась хвилинка часу, для цього.

Методика тестування

За основу для написання тесту я взяв свій невадалий тест для перевірки швикдості виклику методу в java.

Однак тоді виникла проблема з тим, що JIT від Sun дуже добре передбачає такі речі, як розрахунки та виконує їх миттєво. Тому в якості методу, який я викликаю, я вирішив використовувати щось складніше ніж простий інкремент. Вирішив використовувати суму випадкових чисел, де кожне наступне число отримується за формулою:

Перший член такоъ послідовності береться на основі миттєвого таймштампу. Такий генератор випадкових чисел хоч і є дуже брудним, однак працює доволі непогано для широкого діапазону значень max та min.

Магія відображень.

Ніколи не замислювались, яким чином прицюють IDE, що дозволяють на льоту підхоплювати список методів та полів класу, з усіма правилами доступу та списком параметрів. Коли вперше побачив таку штуку, це здавалось фактично ідеалом. Не знаю як там в з іншими мовами програмування, а для Java є досить проста технологія, що дозволяє роботи такі цікаві штуки, як доступ до властивостей та методів будь-якого класу, там самим відкриваючи можливості легкого написання інтегрованих середовищ для розробки, різноманітних відлогоджувачів, середовищ для тестування. Сьогодні хочу розповісти про чудову можливість, що присутня в мові java - Java Reflection API.

Для того, щоб цікавіше було розбиратись з усим цим, пропоною в процесі роботи поставити собі за мету розробку такого "велосипеду" - простої автоматизованої системи тестування коду написаного на java. Звичайно ж системи простої, однак основні принципи роботи Reflection API та систем автоматизованого тестування зрозуміти можна і на невеликому прикладі.

Погляд на MySQL proxy

Останнім часом я аж дві статті присвятив СУБД PosgreSQL. Як Ви могли помітити, мені дуже подобається ця СУБД. Хоча й MySQL моєю увагою в щоденній роботі необділена. А ось інформацією про неї я не ділився. Просто нічого цікавого, про що б не написали на кожному кроці на думку не спадало. І ось я мені випала можливість познайомитись з не дуже освітленими аспектами роботи з MySQL, а саме побудовою систем проксювання запитів для MySQL та утилітою MySQL proxy.

Взагалі матеріалів з цього приводу доволі мало, не те що українською, а навіть і англійською мовою, тому з гордістю хочу розпочати написання невеличкої серії статей про те, як можна зменшити навантаження на СУБД MySQL, шляхом проксювання запитів через MySQL proxy.

Вигадуючи велосипеди

Дуже давно в мене бажання написати відповідь на одну статтю з "Української блогосфери". Справа в тому, що моя позиція суттєво відрізняється від написаного у тій статті. Вимушений допустити, що це диктується моєю підсвідомістю, яка не хоче визнавати, що помилковим може бути обраний мною шлях роботи над власноруч написаною CMS, яка базується на знову ж таки власноруч написаному framework. Але мій розум, що цілком можливо потопає в самообмані, підказує ряд причин, чому я пішов саме таким шляхом. І нарешті я дозволю собі задовольнити це бажання і розповім, які ж причини того, що я так люблю писати все своїми руками.

Необ'єктивність

З самого початку ери комп'ютерних технологій частина програмістів з радістю займається не використанням вже написаного програмного коду, а пише ту чи іншу частину програмного код своїми руками, нехтуючи вже створеним функціоналом. І таке ось вигадування "колеса" продовжується і по сьогоднішній день, і я впевнений, буде продовжуватись до кінця ери людської. Та що ж казати: у всіх сферах людської діяльності є любителі йти незвичним шляхом.

Якщо спитати кожного з них про причини такого підходу, отримаємо досить просту відповідь: "Навіщо мені користуватись тим оцим непотребом, якщо я можу зробити краще?"

На цьому місці слід хапатись за голову, волати: "Як краще? Та куди тобі! Ви подивіться, яке зухвальство..." Так, так, я теж вхожу до списку тих людей які впевнені, що можуть переписати більшість програмного коду так, що він стане від того краще. Буде працювати швидше, буде мати більше функціоналу, займатиме менше пам'яті чи хоча б просто виглядатиме логічніше, зрозуміліше та приємніше.

Крихітка Lua

Серед звичних та відомих всім у світі ІТ великих мов програмування можуть загубитись маленькі перлини. І мова йде не про perl, що з кожним роком стає за моїми спостереженнями все менш популярним, дарма що це одна з найпотужніших мов, яка обов'язково заслуговує на увагу до себе. Мова йде про ще більш "загублені" мови, які навіть ніколи не досягали популярності perl'а. Відверто кажучи я й сам особливо не звертав на такі мови програмування уваги, а от коли довелось познайомитись з мініатюрною скриптовою мовою Lua, я не пожалкував ні про один день з тих двох тижнів, що були проведені з цією крихіткою.

Lua ([лу́а], порт. місяць) - "ще одна" інтерпретована мова програмування, що є вільно розповсюджуваною, має відкритий програмний код мовою С та широко відома у вузьких колах розробників... та на відміну від більшості інших подібних мов, про неї чули також і допитливі фанати комп'ютерних ігор. Чому? Та тому, що це скриптова мова, що використовується в популярних World of Warcraft, The Witcher, Warhammer Online, S.T.A.L.K.E.R. та ще десятки хітів.

Думаю вже цього має вистачити для того, щоб зацікавитись мовою. Не дарма ж розробники стількох проектів її використовують?

Компанії та люди

Останні два роки я не працював у великих колективах - заробляв собі на життя то фрілансом, то роботою в невеличкій команді. Хоча починав свій робочий шлях я ще в роки навчання в університеті в рамках лабораторії дистанційного навчання того ж самого університету. І ось тепер вже третій місяць працюю у досить великій компанії, де наш дивізіон хоча й не може боротися за звання найбільшого, однак все ж таки за чисельністю практично досягає кількості в півтори сотні співробітників. При цьому обслуговує більше 50 тис. абонентів. І знову ж скажу, що це не найбільший за чисельністю та абонентською базою дивізіон.

Навіть тих трьох місяців, що я працюю в цій компанії мені вистачає для порівняння з тими двома роками, що я провів в межах університетської лабораторії. І що не дивно, я знайшов стільки спільних рис. Ось наприклад анкетування співробітників, з метою оцінки їх ступеня лояльності компанії, настроїв, побажань і т.д. Перше ж питання в цій анкеті викликало в мене посмішку своєю шаблонністю для подібних структур. Виглядає воно приблизно так: "Чи дає Вам компанія А можливості для професійного розвитку та самореалізації?" Ось відповідь на це питання я й вирішив написати.

Google Chrome в Linux

Майже рік минув з того часу, як корпорація Google випустила власний браузер Chrome, що зайняв доволі значні позиції на ринку браузерів за короткий термін часу. Нажаль, випущено було лише версію для Windows. Це можнор джосить легко пояснимти: компанія не вважає доцільним працювати над паралельною розробкою нового продукту для декількох платформ одночасно. В Google епообіцяли, що коли версія для Windows стане стабільною, отримає весь необхідний на думку компанії функціонал, встане на ноги, тоді буде зроблено версії також і для інших ОС. Зрозуміло, що у тому випадку, коли браузер не займе серйозну нішу в рамках найбільш розповсюдженої серед користувачів платформи, то сенсу витрачати додаткові ресурси на розробку. Та й розумно написаний програмний код легше переносити на іншу платформу, ніж писати паралельно під декілька платформ.

Ну зрозуміло, що community не дуже зраділо такій політиці компанії, та створило порт opensource-проекту Chromium для інших ОС - Crossover Chromium. Свого часу спробував я його власними руками. Добре, що він існує і став для мене вікном через яке я подивився на Chrome, та до основного продукту він не дотягує: значно поступається за швидкодією та стабільністю. Та що ж взагалі просити від wine? Ось тепер і на вулиці прихильників Linux з'явився браузер від Google. Тепер будь-хто може спробувати рідну версію Chrome для цієї ОС. Спробував і я, та вирішив поділитись враженнями від побаченого.