От мейнфрейм COBOL до обектно-ориентираната бездна: смущение в силата
Преди малко, в рамките на град Чикаго, може да има разговор между амбициозен разработчик на Python, голям майстор на Python и лидера на Съвета на Python, който обсъжда дали да поеме чирака да го обучава на начина на рицар на Python. мина нещо подобно...
Велик майстор: Не мога да го науча. Той не знае какво означава обектно ориентирано.
Лидер на съвета: Той ще научи обектно ориентирано.
Велик майстор: Хммм. Много инат в него, като баща му.
Лидер на съвета: Бях ли различен, когато ме учехте?
Велик майстор: Ха! Той не е готов.
Разработчик на Python: Готов съм! Мога да бъда Python Knight. Python Council Leader, кажете му, че съм готов!
Велик майстор: Готови ли сте? Какво знаеш за готов? В продължение на 26 години съм тренирал Python Knights. Моят собствен съвет ще продължа ли кой да бъде обучен! Рицарят на Python трябва да има най-дълбок ангажимент, най-сериозен ум. Неефективен, чуплив, нечетлив код. Python Knight не жадува за тези неща... Вие сте безразсъдни!
Лидер на Съвета: Аз също бях, ако си спомняте.
Велик майстор: Той е твърде стар. Да, твърде стар, за да започна обучението.
Разработчик на Python: Но аз научих толкова много!
Велик магистър: *въздъхва*...Ще завърши ли започнатото?
Разработчик на Python: Няма да ви проваля — не ме е страх.
Не опитвайте. Направи. Или не го прави. Няма опит.
Няма да овладея Python до края на тази менторска програма, но ще създам основа, от която мога да използвам добре Python и да усъвършенствам още повече уменията си. И се надяваме, че ще спрете да чувате гласа на Йода в главата си, докато четете останалата част от този блог. :)
Ето ме във втория месец от програмата ChiPy Spring Mentorship и не само разработих доста добро управление на Python, но и научих много по отношение на най-добрите практики. Ранните скриптове, които написах, биха се считали за крехки, тъй като нямаше обработка на изключения, а основните процедури бяха дълги и нечетливи с малко използване на дефинирани функции. Сега кодът, който разработвам, е много четим с процеси, разделени на по-малки функции с по-дълги, но по-описателни имена (все още усъвършенствам това). Всички непредвидени грешки доведоха до срив на тези ранни модули, но сега, използвайки различни техники за обработка на изключения, моят код ще идентифицира и улови потенциално сериозни грешки. Когато това се случи, контролът се предава обратно на операционната система с подходящи кодове за връщане, така че системата да може да предприеме дефинирани действия и това също така позволява на манипулаторите да затварят спретнато свързани системни задачи.
Също така се научих да регистрирам информационни съобщения на подходящи нива (информация, критично, отстраняване на грешки и т.н.), докато скриптовете се изпълняват с помощта на функцията за регистриране. Тези съобщения са полезни, за да знам какво правят моите скриптове и важните параметри и източници на данни, които се препращат или създават, а също така се оказват много ценни, когато трябва да отстранявам грешки. Това са само няколко примера, при които кодът, който предоставям, е написан с помощта на най-добрите практики за кодиране, но аз също уча и прилагам най-добрите практики, използвани през целия жизнен цикъл на разработка.
Но как стигнах дотук и накъде отивам от тук нататък? Прочетете...
Пътната карта
След няколко първоначални разговора, за да разгледам моя опит и цели, заедно с някои идеи за проект, Алън състави „Пътна карта“ за това, което трябва да науча по време на тази програма. Следните са пътищата, по които трябваше да вървя, преди да завърша основното обучение и да стана млад рицар на Python:
Основен Python 101› За цикли, If/Elif/Else, навигация в речник, навигация в списък, работа с кортежи, работа с низове, запис във и четене от файл.
Advanced Python 101› Аргументи на командния ред, създаване на модули (извикващ контекст и __main__ kinks), flake8/PEP8, doc strings/PEP257, разбиране на списъци, „с“ контекстен мениджър, обработка на изключения, класове, още като те му хрумнаха (това беше моят личен фаворит), парсване на XML, regex.
Git 101› Комитиране и натискане, ангажиране на клон и натискане, сливане на клон, разрешаване на конфликти, заявки за изтегляне на GitHub и нека не забравяме .gitignore.
Тестване 101› Напишете тестове, за да потвърдите изхода на моя скрипт, настройте Continuos Integration в GitHub за бонус точки. Това бяха специални изисквания към мен от инженер по качеството.
Завършване на Python 101
Не само развих добро разбиране на елементите в Пътната карта, в някои случаи демонстрирах разбиране над очакванията на Алън. Понякога откривах алтернативни методи и ги използвах, след което обсъждах с Алън. Поставих под въпрос много неща и мисля, че предизвиках Алън почти толкова, колкото и той мен.
И така, след шест дълги седмици с много късни нощи и безброй регистрирани часове и без истинска фанфара, спечелих достатъчно точки, за да завърша Python 101. Това беше огромна стъпка за мен, особено като се има предвид, че идвам от периода на COBOL в ерата на мейнфреймите на технологичната времева скала. Този динозавър се чувства доста страхотно от това, което е научил досега и е готов да го използва добре и да научи още повече. Така че вземам това, което научих, и изграждам система в облака. Да поговорим за моя проект!
Пролетен менторски проект за 2017 г.
Мислите ли, че Торо някога е мечтал, че хората 160 години по-късно наистина ще строят замъци във въздуха? Е, ние не строим истински замъци, но и той не говореше за тях в буквалния смисъл. Всички имаме мечти. Аз имам моите, а вие имате вашите и ако искаме мечтите ни да се сбъднат, трябва да бъдем креативни и да вложим истинска работа в тях.
Кой не обича добър бейзболен мач, особено ако сте фен на Cubs в наши дни. Избрах да разработя малка система, съсредоточена около извличането на бейзболна статистика до минута, и тази система ще бъде изградена в облака, което само по себе си е друга чудесна възможност за обучение. Моят ментор Алън играе фентъзи бейзбол и аз самият съм го играл в миналото. Получаването на актуална информация за играчите от вашия фентъзи отбор е голяма работа, тъй като собствениците на фентъзи бейзболен отбор искат да знаят как се справя техният отбор във всеки един момент. Това не само звучеше полезно, но и доста забавно.
Мейджър лийг бейзбол има сървър за данни, където те съхраняват информация за всички мачове през годината, дори тези, които са в ход. Директориите на този сървър са много организирани и използват JSON речникови файлове за запис на данни, докато се играе, и са достъпни за всеки. Няма MLB API, които мога да използвам за достъп до данните. Ами всъщност има, но аз не съм предпочитан партньор на MLB (мисля за ESPN), така че докато системата ми не получи национална известност, аз съм просто обикновен потребител на тези данни. Проучих сложната структура на тези речници и разбирам как те сочат един към друг и как се съхраняват съответните данни. Ще трябва да създам главни файлове, за да изпълнявам ефективно моите скриптове за заявки и те ще се съхраняват в структурирани JSON речници.
Оказва се, че данните се актуализират в рамките на приблизително 25 секунди след удар на играч, така че наличната информация е доста навременна. Планирам да разработя поредица от скриптове и уеб/мобилни интерфейси, които ще осигурят средство за изискване на MLB статистика за желани играчи. Резултатът ще покаже данни, свързани с фентъзи бейзбола, тъй като точките се присъждат въз основа на представянето на играча по отношение на някои ключови статистически данни за хвърляне и удари. Но първо трябва да завърша скриптовете, които пиша, за да извличам данни на ежедневна и дори ежечасна база, за да създам и поддържам тези главни речникови файлове, които споменах. Вече съм ги написал, но променям, докато ги преглеждам с Алън.
И тогава това се случи...
Да, наистина го направи. Алън и аз прекарахме 4 часа в таверна миналия петък и наред с други неща създадохме акаунт в AWS и настроихме моето облачно копие да хоства моята MLB система за извличане на данни. Ние не само го настроихме напълно с всички необходими инсталации и настройка на сигурността на SSH, ние го свързахме с моя акаунт в GitHub и пренесохме първите няколко скрипта, които вече бях написал. Решихме да ги раздвижим… и познайте какво, те се представиха успешно още от първия опит! „Не може да бъде!“ - възкликна Алън, "Това не се случва, не и от първия опит!" След като потвърдихме резултатите, ние дадохме пет, определихме някои следващи стъпки и приключихме.
Споменах по-рано, че бях развълнуван, че завърших Python 101 с отличие. И така, представете си вълнението ми при настройването на облачен екземпляр на AWS и всъщност получаването на няколко скрипта за изпълнение при първия ми опит! На път съм да предоставя системата, която описах, и нямам търпение да представя статистика на очакващ фентъзи собственик на бейзболен отбор зад приятелски потребителски интерфейс. Това става все по-забавно с всяка прогресия! Определено има смущение в Силата в моя свят, тъй като научавам много нови умения, съсредоточени около Python, които мога да използвам чудесно и това ще окаже влияние върху компанията, за която работя, и личното ми удовлетворение.
В моя последен блог следващия месец ще навляза в подробности за различните части, които ще създам в облака. Ще обхване източниците на входни данни и как те се свързват помежду си, речниците, които създавам, за да стигна бързо до желаните данни, и някакъв ключов код зад услугите, доставящи съдържанието на потребителя. Ако искате да следвате, можете да прегледате моя акаунт в GitHub тук...
Свежа перспектива: Актуализиран
В предишния си блог дадох гледна точка на разликите и приликите между света на Python/Object Oriented, в който навлязох наскоро, и света на мейнфрейм COBOL, от който идвам. Цитирах как те са значително различни в използваните технологии и това е очевидно, но също така говорих за това как основните принципи са наистина еднакви в двете.
С още един месец на развитие и нарастващо използване на най-добрите практики под колана си, все още поддържам позицията, че световете са технически различни, но много сходни. През последните две седмици, когато започнах да разработвам моите скриптове за тази облачна система, сега следваме това, което се нарича Trunk Based Development.
Тази концепция наистина не се различава от това, което използваме в света на мейнфреймите, което наричаме Enterprise Release. Един до много екипи, притежаващи различни части от системата, работещи в единство, за да направят подобрения или да разработят нови функции на съществуващата система и да се обединят по организиран начин, за да разработят, тестват и пуснат кода в производство. Това се контролира от Release Coordinator, който управлява въвеждането на всеки нов код в тръбопровода (или ствола), като гарантира, че екипите не си стъпват по пръстите, и управлява инсталациите в различните тестови и производствени среди. Технологията е различна, това е даденост, но отново основните принципи са същите.
Юни е зад ъгъла…както и последният ми блог…оставайте на линия!
О, и между другото… все още получавам безплатна пица на всяка среща! #togoodtobetrue #thankyouChiPy
