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

Люблю шорткати.
Не те, щоб вони дозволяли робити деякі буденні речі набагато швидше, ні. Вони трохи прискорюють та додають динамічності, як на мене.

Увесь час свого знайомства з ПеКа (а це приблизно 20 років з Windows та 9 років з *bunu-подібними ОС) використовую "Alt+Tab", проте лише досить недавно дізнався про комбінацію "Super+`" (апостроф, "Ё", тільда) - перемикання між вікнами одного й того самого додатку. В мене завжди то дві-три IDE з різними проектами відкрито, то PgAdmin з декількома вікнами, то ще щось подібне, і по альт-табу перемикатися в межах додатку - таке собі задоволення.

А для ноутбуків, що не мають клавіші "контекстне меню", в Наутилусі/Немо/іншомуФайловомуМенеджері буде в нагоді комбінація "Shift+F10".

#linux

Гострота, що віддзеркалює
#knives

От тільки шо перейшов на одну з табочок github-а та помітив, шо в нього змінився дизайн. Тепер - більш material та більше корисної площі використовається.
Мені довподоби. А вам?

P.S.
В контексті того, шо деякі наші проекти зараз переживають редизайн (та все ніяк не переживуть), наша PM/BA пошуткувала: "хоть кто-то редизайн уже выкатил" 😄

UPD: ...а хлопець з проекту додав: "Главное, что не Martyrial".

За час, що пройшов з тієї пори, коли я змінив роботу з інженера на девелопера (спочатку фулстек, але згодом вирішив спеціалізуватися лише на бекенді), в мене декілька разів питали щось накшталт:

Скільки-скільки ти співбесід пройшов? Вісім? І шо - тільки з восьмої спроби взяли?.. А з якої?.. З другої? А чому не пішов туди? Нашо було далі вчитися, моніторити ринок вакансій, розсилати резюме десятками, ходити далі по співбесідах?.. Можна ж було одразу "войті в ойтішечку" та "поднімать бабло на джавє" .

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

Про співбесіди, офери і т.ін.
Вийшов лонґрід.

Перший офер я отримав від невеликої продуктової компанії. Досить зручне розташування, невимушена атмосфера в офісі, цікаві технології (вже по-о-отім я дізнався, шо одна з тих технологій вже мертва, але про це далі), відсутність вертикалі керівників - усе це дуже сприяло.
Так, оце останнє, хоча і є нормою для більшості IT-компаній, та для мене то було дивним дивом. Я майже 10 років пропрацював на великому підприєстві, де, нажаль, була вибудувана багаторівнева система керівництва, яка, як мінімум, гальмувала ініціативи та "спускала зверху" рішення. Такі рішення майже ніколи неможливо було виконати в означені терміни, і терміни тре було переносити, переносити, переносити, а для переносів тре було вигадувати причини. Ніколи не забуду, як переносив видання одного технічного документу за тематикою циклонів/антициклонів:) десь 12 разів упродовж півроку.
Чому так? Все просто: рішення приймалися без залучення спеціалістів, які будуть їх виконувати.
...Чотири вечори та два вихідних дні я вивчав невідомий тоді мені java-фреймворк (ні, не Spring) та робив тестове завдання. Фронтенд, бекенд, реляційна базка... було дуже цікаво.
Отримавши офер, я світився від радості. Але на наступний день, коли ще не встиг дати свою згоду, дізнався, що продукт, на який мене беруть, по-перше, орієнтований на країни СНД, а в першу чергу - на московію, а по-друге, продукт пов'язаний з рекламою. Ну, ви зрозуміли... Та і від процесу "рекламувати щось" мене трохи блювати тягне.

Одна з компаній мала аутсорс-проекти в специфічній, але цікавій доменній області, та все там було на Java 6. І дотепер ці проекти живуть на ній, на шостій. Це був 2016-й, вже навіть тоді Java 6 була не дуже.
Я мав вибір - цікава доменна область, але технології, в яких, найвірогідніше, не буде шансів підвищувати свої скілли. Так, завжи є pet-проекти, але на них треба мати час і натхнення.
Перемогло бажання користуватися найсучаснішим.

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

Інколи і місце, і умови можуть були добрими, та стек технологій і тематика - ну зовсім нецікаві. Наприклад, для мене таким виявилося Salesforce. Я подивився на мову програмування (як java, але досить урізана), на місцеві аналоги JSP, ORM - і стало сумно. Ще додам, шо десь 70% стаффу тре буде будувати мишею через GUI - так розказували хлопці, що проводили мені співбесіду, - і лише 30% - через написання коду. А з IDE на той час були лише онлайн-IDE (ага, в браузері) та плагін на Eclipse... Так, там були приємні люди, атмосфера, сама компанія дуже мала, затишна, все таке... Але я зрозумів, що десь через пів-року така робота набридне і я піду шукати нову.
Тому я не там.

Так, і звісно ж були компанії, які після свівбесіди давали фідбек у дусі "Дякуємо, але ні". Ну шо ви хочете, джуніор без комерційного досвіду роботи.
Та негативний фідбек - це теж результат! Нажаль, була одна компаанія, що не дала ніякого. Навіть коли через два тижні мовчання я звернувся до рекрутера email-ом з проханням про фідбек. Але ні, тиша. Ну що ж, буває.
В ті часи я хотів потрапити до них на безоплатне стажування, з шансом отримати роботу. Мені сподобалося відношення до людей, яке я побачив на співбесіді. Бува.
Через декілька років декілька гарних спеціалістів прийшли звідти працювати до нас, в мою команду. Чому я впевнений, що вони гарні? Я якраз був одним з тих, хто проводив їм співбесіди, та деякий час ми працювали разом "в одному коді" :)
Я послухав, чому хлопці пішли. Знаєте, я дуже зрадів, що колись мене туди не взяли:)
Так ось. Навіть негативні фідбеки - це насправді позитивні фідбеки. З кожної співбесіди виносиш одну-два-декілька нотаток - я для цього зі спеціальним блокнотом ходив. Інколи навіть декілька аркушів нотаток виносив. І потім все це розбирав.

До чого я оцю всю єресь пишу?

Коли є час - не тре спішити. Так, у мене були деякі складнощі, які неможливо було вирішити на попередній роботі, але деякий запас часу в мене був. Тре шукати себе і мацати те, що подобається, те, що надихає.
Якщо новою роботою має стати хобі - це прекрасно. В мене воно так і вийшло - кодінг, реляційні базки, гіт - це любов. Деяка - давня та чиста. Ось один мій друг (у минулому - теж інженер на великому державному підприємстві) мав добрі скіли в лінуксі та в ангєльській мові - і після DevOps-курсів, до яких була додана величезна крихта самонавчання, величезна крихта бажання щось міняти та не менш величезна крихта не-бажання сидіти на дупі рівненько, він пішов у девопси. Консоль, лінукси, ssh, ансібли та інші загадкові слова. І зараз десь у хмарах тусить, норкоман чьортов:)
Відволікся...

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

Десь так.

Доречi.

Акції проти мовного законопроекту #2362 "слуги у...народу" Бужанського пройдуть:

- в Дніпрі в середу 15.07 о 19:00 біля офісу партії "слуга народу", вул. Європейська 20
https://www.facebook.com/events/995357474232979

- в Днiпрi в четвер 16.07 о 9:00 біля ОДА
https://www.facebook.com/events/3218376101539294

- в Києві 16.07 о 9:00 біля ВР
https://www.facebook.com/events/307160920652509

Досить немала частина тих, хто працює з git, має хибне уявлення про термін "гілка" (branch).

Гілка (а точніше, ім'я гілки) - це динамічний вказівник на коміт. Все.

Чому динамічний? Коли на гілці з'являється новий коміт, вказівник автоматично переміщується на нього. Зазвичай гілка не вказує на один і той самий коміт впродовж усього свого існування (так, таке може бути, але лише в окремих випадках).
На малюнку "master" - це вказівник на коміт a11 (коміти позначені умовно - для спрощення), "feature-1" - вказівник на c4, а "feature-2" - вказівник на b5.
Більшість команд, що мають на увазі коміт, з задоволенням приймуть ім'я гілки: наприклад, git diff.
Але навпаки - не завжди: наприклад, git checkout. Checkout на коміт спрацює, та зробить він трохи не те, що вам хотілося.

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

#git

А ось і "Perseverance" пішов. Привіт Марсу хай передає.

"Perseverance/Mars 2020" - це місія на Марс, що забезпечуться ракетою-носієм "Atlas V". Марсохід та коптер дістануться червоної планети у лютому 2021-го.

Трохи міських ДЮЄ.
Житловий масив Червоний камінь, Дніпро.
#places

Ахрана Git, атмєна
або
Як вилучити з репозиторію зайві файли, що були додані декілька комітів тому

Минулого тижня товариш з сусідньої команди звернувся з запитанням.

Дано
1. Коміт, до якого помилково потрапив зайвий файл. Також в ньому наявні інші (потрібні) зміни.
2. Після нього зроблено ще декілька корисних комітів.

Треба
Вилучити зайвий файл з історії.

Що нам НЕ підійде
1. Просто видалити файл та зробити коміт.
2. Revert: git revert хешКоміту.
3. Amend: git commit --amend.
4. Hard reset: git reset --hard хешКоміту.

#git

...Чому не підійде?
1. При "просто видаленні" файл зникне з файлової системи, але залишиться в історії.
2. Revert, як і в п. 1, не прибере зайвий файл з історії, а ще ми втратимо ті потрібні зміни, що були закомічені разом з нашим зайвим файлом. Так, ці зміни можна буде отримати досить законними шляхами, але нашо ті танці? Все одно історія не буде змінена, що унеможливлює використання цього способу.
3. Amend виправляє лише останній коміт. У нас проблема не в останньому коміті, а глибше.
4. Після хард резету ми втратимо усі корисні коміти, що зроблені після проблемного, а також ті потрібні зміни, що знаходяться у проблемному.

Що ми будемо робити?
Ми будемо робити інтерактивний рібейз.
Інтерактивний рібейз - це один зі способів переписування історії. Він дозволяє редагувати коміти, переміщувати, зливати їх і т.ін. При цьому гілку ми будемо перебазовувати саму на себе.

Як ми будемо це робити?
Спочатку вилучимо зайвий файл та створимо з цього коміт. Потім запустимо інтерактивний рібейз на коміт, що передує проблемному коміту. Перемістимо коміт-рятівник так, щоб він знаходився одразу після проблемного, та вкажемо опцію "squash", тобто зіллємо з попереднім, проблемним. В результаті цього злиття в один і той самий коміт потраплять обидва діффа - той, де зайвий файл створюється, та той, де він видаляється. Повна анігіляція файлу. Як матерія та антиматерія.

#git