Завжди було цікаво дізнатися, що і як думають кодери за океаном? Логічно припустити, що технічне мислення і основні процеси повинні бути схожими з російськими розробниками. Під катом можливість порівняти наші походи з «тамтешніми». Якщо у вас все добре з англійською, оригінал публікації і самого автора можна знайти на за адресою
Читати далі →

image
Частини 1 і 2: посилання
У першій частині ми поговорили про різних стратегіях обробки помилок і про те, коли їх рекомендується застосовувати. Зокрема, я розповів, що передумови функцій повинні перевірятися з допомогою налагоджувальних тверджень (debug assertions), тобто тільки в режимі налагодження.
Для перевірки умови бібліотека З надає макрос
assert()
, але тільки якщо не визначено
NDEBUG
. Однак, як і у випадку з багатьма іншими речами, це просте, але іноді неефективне рішення. Головна проблема, з якою я зіткнувся, — глобальність рішення: у вас є твердження або скрізь, або ніде. Погано це тому, що ви не зможете вимкнути затвердження в бібліотеці, залишивши їх тільки у власному коді. Тому багато авторів бібліотек самостійно пишуть макроси тверджень, раз за разом.
Читати далі →



Існує дві основні стратегії: обробка виправних помилок (виключення, коди повернення помилково, функції-обробники) і невиправних (
assert()
,
abort()
). В яких випадках яку стратегію краще використовувати?

Читати далі →

routine tasks automation

Введення
Машини завжди будуть швидше, незалежно від того наскільки ми продуктивні і як швидко ми набираємо команди. Сувора правда життя. З іншого боку, якщо ми виконуємо одне і теж дія безліч разів, то чому б не змусити машини страждати. Написати скрипт на
bash
(ваш улюблений мова програмування) і кожен раз викликати цей скрипт, а не набирати монотонні команди, які забирають так багато часу, сил та енергії. А ми, поки скрипт буде виконувати свою роботу, можемо помріяти про те, як космічні кораблі борознять простори Всесвіту.

У минулій статті ми розглянули основи програмування на
bash
. Сьогодні ми будемо застосовувати отримані знання на практиці.

Читати далі →

Передмова
Існує велика кількість статей, присвячених статичних аналізаторів для С/С++/С#, Java і т. д. Що стосується досліджень застосування різних статичних аналізаторів для нативної розробки під MacOS/iOS, то їм приділено значно менше уваги.

Пропонується розбір застосування статичних аналізаторів коду, що використовуються в різних проектах на ObjC та Swift. При цьому, це не огляд, а скоріше деякі нотатки застосування різних інструментів, що дозволяють знаходити помилки того чи іншого роду в коді, починаючи від витоків пам'яті і закінчуючи пошуком вразливостей. Однак дані не претендують на об'єктивність та повноту зроблених висновків, а також на глибину аналізу отриманих результатів по кожному інструменту.

Читати далі →

Секрет швидкого програмування: не замислюйтесь



Програмувати швидко — це легко! Так вважає інженер-програміст компанії Google, який всі публікації в своєму блозі підписує лаконічним «Макс». Макс також працює головним архітектором, ком'юніті-менеджером і реліз-менеджером в Bugzilla Project. Ми в Alconost вразили і перевели його поради про те, чи як навчитися програмувати з космічною швидкістю.

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

Вони, звичайно, мають рацію в тому, що в умовах стислих термінів розробники, як правило, будуть писати складний код. Втім, дедлайни не повинні призводити до складності. Замість фрази «Цей дедлайн завадив мені написати простий код» можна вимовити рівноцінну: «Я недостатньо швидко програмують, щоб писати просто». Тобто чим швидше ви як програміст — тим менше впливу на якість вашого коду мають дедлайни.

Тепер давайте розберемося, як, власне, стати швидше? Може, це вроджене магічне вміння? Треба бути «розумнішими» інших, щоб бути швидким?

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

Читати далі →

Помер MVC для фронтенда?


В цій статті хочу поділитися перекладом цікавих роздумів на тему минулого і сьогодення в архітектурі фронтенда.

У той час як все більше і більше фронтенд-розробників переймають підходи до односпрямованої архітектурою, виникає питання — чи є майбутнє у класичного MVC? Щоб зрозуміти, як ми дійшли до такого питання, давайте трохи проаналізуємо еволюцію архітектури фронтенда.

Читати далі →

Інверсії залежностей управління уприскуванням

image

Вступ
Напевно перше питання, яке виникло у вас при погляді на заголовок, був "Шта?". Насправді я просто переклав фразу "Інверсія управління, впровадження залежності" в Google Translate китайський, а потім назад. Навіщо? Потім, що на мій погляд, це хороша ілюстрація того, що відбувається насправді. Люди навколо плутають, перекручують перекручують ці поняття. За службовим обов'язком я проводжу багато інтерв'ю, і 90% того, що я чую, коли ставлю питання про DI — чесно кажучи, відверта маячня. Я зробив пошук по Хабру і знайшов кілька статей, які намагаються розкрити цю тему, але не можу сказати, що вони мені дуже сподобалися (гаразд, гаразд, я продивився тільки три перші сторінки, каюсь). Тут же на Хабре я зустрічав в коментарях таку розшифровку IoC, як Injection of Container. Хтось серйозно припускає, що є якийсь механізм ін'єкції контейнерів, який співіснує десь поруч з DI, і, мабуть, навіть робить щось схоже. Тільки з контейнерами. Мда. Насправді зрозуміти впровадження залежності дуже просто, треба всього лише…

Читати далі →

Чиста архітектура в Python: покрокова демонстрація. Частина 5


Зміст
REST-шар (частина1)
Git tag:Step12

Настав завершальний етап нашого пригоди за чистою архітектурою. Ми створили моделі предметної області, сериализаторы, сценарії та сховищі. Але поки відсутній інтерфейс, який склеює всі разом: отримує параметри виклику від користувача, ініціалізує сценарій зі сховищем, виконує сценарій, який отримує моделі предметної області з сховища, і перетворює їх у стандартний формат. Цей шар може бути представлений за допомогою безлічі інтерфейсів і технологій. Наприклад, за допомогою інтерфейсу командного рядка (CLI): отримувати параметри за допомогою ключів командного рядка і повертати результат у вигляді тексту на консолі. Але та ж базова система може бути використана і для web-сторінки, яка отримує параметри виклику з набору віджетів, виконує описані вище кроки, і розбирає повернені дані у форматі JSON для відображення результату на тій же сторінці.

незалежно від обраної технології для взаємодії з користувачем, збору вхідних даних та надання вихідних результатів, нам необхідно взаємодіяти з нещодавно створеної чистої архітектурою. Тому зараз ми створимо шар для винесення назовні API для роботи з HTTP. Реалізовано це за допомогою сервера, який надає набір HTTP-адрес (кінцевих точок API), при зверненні до яких повертаються деякі дані. Такий шар зазвичай називають REST-шар, тому що, як правило, семантика адрес схожа з рекомендаціями REST.
Читати далі →

Чиста архітектура в Python: покрокова демонстрація. Частина 4


Зміст
Сценарії (частина 3)
Git tag:Step09

Наша реалізація відповідей і запитів, нарешті, завершена. І тепер ми можемо реалізувати останню версію нашого сценарії. Сценарій коректно повертає об'єкт
<font color="#900">ResponseSuccess</font>
, але досі не перевіряє коректність вхідного запиту.

Давайте змінимо тест у файлі
<font color="#900">tests/use_cases/test_storageroom_list_use_case.py</font>
і додамо ще 2 тіста. Отриманий набір тестів (після фікстури
<font color="#900">domain_storagerooms</font>
) виглядає наступним чином:

Читати далі →