Чем отличается пользователь от программиста: Чем отличается программист от пользователя одним словом?!​

Содержание

Чем хакер отличается от программиста

Взломщик

Чаще всего понятие «хакер» ассоциируется со специалистом, который занимается взломом программного обеспечения, поиском уязвимостей в программах, операционных системах и компьютерах. В данном случае хакер обязательно должен являться программистом достаточно высокой квалификации, который должен хорошо владеть как минимум 1 языком программирования и знать структуру и построение компьютерных приложений.

Хакеры хорошо знакомы с теорией компьютерной безопасности и сетей, знают технологии передачи данных и распространенные ошибки программистов, чтобы осуществить взлом программного продукта или целого компьютера (сервера).

Деятельность хакеров не всегда направлена на уничтожение какой-либо информации или завладение доступом к тому или иному интернет-ресурсу. Существуют специалисты, имеющие большой опыт программирования и написания приложений. Такие хакеры работают в крупных компаниях в качестве исследователей уязвимостей IT-систем, которая построена на предприятии и может хранить большие массивы данных.

Работа специалистов заключается в усовершенствовании систем безопасности с целью сохранения работоспособности ПО и обеспечения максимальной степени сохранности данных.

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

Другие значения

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

Термин «хакер» иногда используется по отношению к людям, которые по своему роду деятельности не связаны со сферой IT, однако являются настоящими специалистами в своей деятельности.

Слово «хакер» раньше использовалось по отношению к людям, которые исправляли ошибки в работе программ. Нужные исправления вносились в экстренном порядке, чтобы быстро решить какую-либо проблему в безопасности или исправить ошибки, возникающие в процессе использования приложения.

Кто будет править миром через десять лет

В Кремниевой долине о российской компании Parallels знают гораздо больше, чем в России. У нас и пользователей Apple немного, и с хостинговыми центрами туговато, а это две основные категории клиентов Parallels. Компания почти полностью создает программное обеспечение в России и почти полностью продает его в США, Германию, Японию и делает свой годовой стомиллионный оборот (долларов, конечно), не привлекая к себе внимания соотечественников.

Обычно со словом «IT-компания» ассоциируется просторный яркий офис, по которому на самокатах рассекают молодые и перспективные без пяти минут миллионеры, всюду разноцветные кресла-мешки и игровые приставки. Офис Parallels, затерянный глубоко в Отрадном, больше напоминает нечто среднее между космическим кораблем «Энтерпрайз» из «Звездного пути» и научно-исследовательским центром: длинные светлые коридоры, небольшие ячейки рабочих мест, сверху донизу исписанные формулами школьные доски и огромные шкафоподобные дата-центры, напичканные проводами.

Готовясь к интервью, я пересмотрел гигабайты фильмов и сериалов об IT-компаниях, программистах и как конченый гуманитарий приготовился к встрече с неземной цивилизацией. Но мои опасения не оправдались и наполовину.

Краткий нердо-русский словарь

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

Нерд — это странный, замкнутый человек, чья интеллектуальная активность превалирует над всеми другими. Часто нердами называют блестящих специалистов в каких-то областях знаний. Знаменитые нерды массовой культуры — физики Шелдон Купер и Леонард Хоффстедер из сериала «Теория большого взрыва». В реальности нердами считают Альберта Эйнштейна, Марка Цукерберга и Билла Гейтса. Это слово прицепилось к представителям естественных наук и IT-индустрии, но нердом вполне может быть специалист по поэзии «озерной школы». Найти каноничного представителя вида в природных условиях довольно сложно, и совсем не обязательно, что люди, о которых пойдет дальше речь, являются нердами. Нерд — метафизический герой нашего времени.

IT — две главные буквы инновационного бизнеса, расшифровываются как informational technologies. Это комплекс дисциплин, связанных с хранением, обработкой и управлением информацией. Сегодня в IT происходит что-то вроде золотой лихорадки: в этой области за короткое время можно построить многомиллионную корпорацию. «Яндекс», Facebook и Twitter — это IT.

Программист и разработчик — многие путают два эти понятия, потому что в последнее время они и правда основательно переплелись. Программист выстраивает программный алгоритм (пишет код) — это его основная задача. Разработчик — тот, кто видит архитектуру программы, анализирует задачи и ищет решения. То есть исповедует системный подход. Хотя и код тоже может написать. И программистов, и разработчиков часто называют нердами. Несколько реже они ими и являются.

Parallels — российская IT-компания, деятельность которой в двух словах не объяснить. Одно из направлений — создание программного обеспечения, которое позволяет пользоваться программами Windows на Mac без перезагрузки. Другое — автоматизация хостинговых и телекоммуникационных компаний, это уже настолько сложно, что лучше и не вникать. В общем, 17 международных офисов, внутренняя переписка на английском, больше 150 патентов и упомянутые выше 100 миллионов долларов в год. Не говоря уже о том, что основатель и владелец компании Сергей Белоусов — признанный гуру всех российских нердов, а Parallels — лишь часть его быстрорастущей IT-империи.

О яблонях

По голливудскому канону житие нерда выглядит примерно так.

Он маленький очкарик из хорошей еврейской семьи, в школе футболисты макают его головой в унитаз, большую часть времени он проводит с себе подобными, зачитывается книгами и ковыряется с чем-то непонятным в родительском гараже. В университете выясняется, что очкарик — гений: он придумывает какую-нибудь крутую программу, и миллионы сами сыплются к его ногам вместе с королевами выпускного бала.

Это, конечно, сказки. Если такое и было, то на заре программирования, когда Стив Джобс с друзьями собирал свой первый макинтош.

История разработчика Александра Гречишкина идет вразрез с голливудским стандартом. Сейчас он работает в Parallels — занимается интеграцией разных операционных систем. Но в большое программирование пришел почти случайно — из-за двойки по русскому языку.

— Вообще, я не хотел становиться программистом. Я всегда любил мотоциклы и машины, даже поступал в автодорожный техникум, но провалил экзамены: написал сочинение на двойку. Пришлось идти в 9-й класс. Потом один товарищ показал мне компьютер, — о первом контакте с ним Саша рассказывает с какой-то особой нежностью, как о юношеской влюбленности.

— Первое, что я спрограммировал, была игра «Боа». Ну, змейка. Книжек тогда не было, ничего не было, и получилось очень хардкорно. Мне понравилось — после мотоциклов это был космос практически.

За первой любовью последовало и первое разочарование:

— Желание все разбирать и разглядывать у меня отпало в 90-е, когда был дефолт. Я занимался перепродажей компьютеров. Как-то ко мне попал маленький, но дорогой ноутбук. Он был очень здорово сделан, и мне захотелось посмотреть, что же у него там внутри. Часа в два ночи я начинаю его разбирать и обрываю шлейф, который ведет от видеокарты к монитору. Покупатель за ноутом утром придет, шлейф взять негде. Паял я его до утра. Все сделал, начал собирать. Вдруг внутри раздался «вщщик», и два следующих месяца я работал на этот ноутбук.

С тех пор сильно изменилось и программирование, и программисты.

— Когда я начинал, программистов как таковых и не было, — говорит Саша. — Все самоучки, грязные, голодные, с большими горящими глазами. Они ничего не хотели делать, кроме как программировать. Нашего брата легко было вычислить: одет как чмо, выглядит как чмо, но очень умный. К сожалению или к счастью, но сейчас это изменилось: мы видим успешных, хорошо одетых и богатых программистов. Вначале достаток, потом уже фанатизм.

— А главная характеристика программиста — «умный» —  со временем не изменилась?

— Вообще, сообразительный программист и умный — это два разных человека. Умный получает задачу и начинает что-то придумывать, решать. Он не думает, нужно ли это на самом деле. Сообразительный идет в гугл. Девяносто восемь процентов всего или уже сделано, или как раз сейчас делается. Сообразительный быстро найдет решение, а умный будет сам изобретать велосипед. И изобретет, но медленно.

— Не делает ли нас гугл глупее? Ведь весь человеческий опыт остается где-то в облаке, и в голове вообще необязательно что-то хранить.

— Я не верю, что технологии делают человека глупее. Это прекрасно, что у нас есть столько суплементарной информации. Вот, например, есть у меня на даче яблоня. Она умирает. Я хочу продлить ей жизнь. Я могу посидеть с ней рядышком, посмотреть на кору, найти рану и понять, что ее надо чем-то замазать. А чем? Наверное, чем-то нетоксичным. Пошел в сарай, взял олифу, покрасил. Но размышлять я так могу очень долго. Второй вариант: я открываю интернет, пишу запрос и получаю конкретное решение. Я стал тупее от этого? Нет. Я смог быстро продлить яблоне жизнь и пошел заниматься своими делами. Сейчас гораздо важнее уметь пользоваться информацией. И если вас отец яблоню не научил лечить…

— Гугл научит.

— Скорее человек, который написал об этом статью. А гугл — бездушная тварь, просто хранилище информации.

О чувстве прекрасного

Максим Катаргин занимается автоматизацией бизнес-процессов корпоративных клиентов и о себе говорит очень иронично:

— Мне знаком этот голливудский образ программиста. Но, как ни странно, в нашем отделе из 20 человек на классического домосидячего толстого очкарика похожу только я. Остальные у нас очень живенькие, несколько кандидатов в мастера спорта, парочка мастеров.

Главные враги Катаргина — нелогично устроенные кусочки мироздания. Раньше в жизни Максима их было много: в девяностые он работал сисадмином в банке. Говорит, что это было царство хаоса и безумия, о своем опыте рассказывает как партизан, сбежавший из нацистского плена:

— Мне, администратору систем, долго отказывали в том, чтобы купить запасной винт для бэкапа (жесткий диск для резервного копирования. — «РР»). Банк — это же коммерческая структура, должны деньги зарабатывать. Но нет, все тратили непонятно куда. Преимущественно на родственников. В бухгалтерии было семь человек, работали только двое. Повелитель уборщиц был вице-президентом, а отдел информатики — на положении уборщицы. Целый год мне не могли одобрить один дополнительный винт за 200 баксов. В итоге в разгар деноминации у нас накрылся единственный винт — 3 января, купить, понятно, ничего нельзя. Вызвали на ковер, и спас меня только ворох докладных о том, что нужен резервный жесткий диск. В итоге мне выдали денег аж на два! — говорит Максим с интонацией победителя.

Он успешно пережил то время, когда программист был чем-то маргинальным. Теперь все знают, что человек, которого слушается компьютер, — босс. За 13 лет в Parallels Максим пробовал порвать с кодом, но не смог: менеджмент оказался делом менее понятным.

— Возьмем программирование. Надо что-то написать. Вот сижу я, подумал, еще подумал, потрындел с умным человеком, а написал некрасиво. Но я хотя бы понимаю, что написал код некрасиво. А в менеджменте я не понимаю, хорошо сделал или нет. Там исключительный ориентир — похвалы. Хвалят — значит, что-то умное делаю. А что же я такого умного сделал? И в чем отличие того, что я сделал хорошо, от того, что сделал плохо? В программировании не надо быть чьим-то родственником, расти годами. Умеешь что-то делать — делай. Умеешь еще больше — делай еще больше. Все прозрачно.

Наверняка многие слабо представляют себе, что такое код. Если совсем коротко и просто: это много-много белых строчек на черном фоне, из которых вы поймете чуть меньше, чем ничего. Максим же говорит о коде как о чем-то возвышенном:

— Обычно я могу легко понять, красив или уродлив код. Человек может прочитать много книг об этом, но если у него нет чувства прекрасного, в профессии он вряд ли выживет.

— А вы любите изобразительное искусство?

— Ну, вкусы у меня простые, примитивные. Я не люблю Пикассо, не люблю «Черный квадрат».

— А почему?

— Они могут выражать какие-то очень умные мысли, но не выглядят красиво. Вот «Демон» — это прекрасно, «Явление Христа народу» — тоже картина впечатляющая.

— Вот вы говорите о красоте кода. Вы что же, воспринимаете его как произведение, достойное эстетической оценки?

 — Скорее да. Но давайте сразу определим, что такое эстетическая оценка. Эстетика рождается из чувства целесообразности. Девяносто процентов того, что мы считаем прекрасным, целесообразно. И код красив в том же смысле: он красив, если не взрывает мозг программисту. Красота прямо связана с функциональностью этого кода.

— Ну, то есть между программистом и художником есть что-то общее. А нужно иметь какую-то искру, чтобы программировать?

— Если средний умный человек с высшим образованием решит, что хочет заниматься программированием, у него с высокой вероятностью получится. Но хорошим программистом получится стать не у всех, а лишь у некоторых. Это как с живописцами: я могу пойти в художественную школу и, скорее всего, смогу на Арбате портреты рисовать. Но вряд ли из меня получится что-то большее.

О судмедэкспертизе

В системе российского образования есть с десяток специальностей, которые можно обобщить до условного «программиста». Но приходят сюда, как и во всякую профессию, далеко не всегда университетские специалисты. Если физику твердого тела переквалифицироваться в программиста довольно легко, то судмедэксперту почти так же проблематично, как и журналисту. Но бывает и такое.

Олеся Новасельская несколько лет смотрела в микроскоп, вскрывала трупы и делала все, что положено судмедэксперту, пока не решилась кардинально изменить свою жизнь.

— Я закончила медакадемию, потому что моя бабуля была очень властной женщиной и точно знала, что и кому нужно делать. С ней никто никогда не спорил, и я в том числе. Поэтому я сначала закончила музыкальную школу, потом медакадемию, хотя желания поступать туда у меня не было. Я училась в группе отличников, и каждый раз, когда я хотела бросить, бабуля говорила: «Лесечка, неужели тебе не жалко, что эти два — а потом три, четыре — года будут потрачены зря?» Нужно было плюнуть на пол, сказать, что пропеллером я это все вертела, и уйти. Но я каждый раз напрягалась и думала, что, наверное, да, жалко, — Олеся яростно жестикулирует и всей своей активной мимикой показывает, как ей не хотелось учиться медицине. — Под эту же шарманку бабуля уговорила меня сходить в ординатуру…

В какой-то момент бабушкино лобби ослабло, и Олеся совершила побег из профессии.

— Я специализировалась на анатомии и судебной медицине, работала судмедэкспертом два с половиной года, даже студентов поучала в Склифе. После окончания ординатуры поработала еще немного и поняла, что больше так не могу. К этому времени я уже познакомилась со своим мужем, который был разработчиком и, конечно, гамал (играл в компьютерные игры. — «РР»). Я тоже стала гамать, высунув язык. Это был совершенно другой мир.

Леся бросила Склиф и перепробовала разные работы: от «Русского радио» до тележки с пончиками. Но остановилась на IT-индустрии.

— Я просто пришла в Parallels — им нужны были тестировщики. И оказалось, что это здорово, это захватывает. А все эти языки программирования похожи на иностранные, — Олеся рассказывает, как прошла путь от ручного тестировщика, которым может стать почти любой, до серьезного разработчика. — Мне, конечно, мешает отсутствие регулярного образования. Людям, которые учились в технических вузах, проще: у них есть основы, они знают теории алгоритмов. Так что я читаю всякие учебники, плюс надо видеть много написанного кода. И у нас его много!

Я слушаю Олесю, и мне кажется, что пропасть между программированием и судмедэкспертизой размером с Гранд-Каньон. Но Олеся находит между этими видами деятельности больше сходств, чем различий:

— Программные крэш-дампы (поломки в операционной системе, ассоциируются с «синим экраном смерти». — «РР») — это прикольно и интересно. И человеческие крэш-дампы — они о том же. У тебя есть какие-то остатки живого организма, и с помощью своих знаний ты можешь разобраться в том, что же там сломалось. Это восхитительно!

Я пытаюсь выяснить у Олеси, есть ли у программистов что-то общее и правда ли, что все они нерды. Она говорит, что почти все играют в видеоигры и правда немного нердоваты. Но тут я понимаю, что главная отличи-тельная черта программиста — это его язык, состоящий из жуткого микса обычного русского, технического английского и загадочного профессионального сленга.

О трудностях перевода

По факту Алекс Пацай продакт-менеджер, но по сути переводчик с языка программистов на язык обычных людей, и наоборот. Он объясняет, чем одни отличаются от других:

— Пользователь хочет достаточно простую вещь — чтобы какая-то его задача выполнялась. В идеале это должно осуществляться одной кнопкой «сделать мне хорошо». Программисты же думают не как пользователи — они выполняют поставленную задачу. Вот сказали им сделать так, чтобы катилось. И колесо, которое они придумают, может получиться совсем не круглым, а шестигранным, но задачу качения оно выполнять будет. Программисты любят сложные технические задачи, и их решение часто тоже выглядит сложным. Вот и получается как в фильме Lost in translation («Трудности перевода». — «РР»). Интерфейс, который сделает программист, может оказаться очень запутанным. А пользователю с маленьким устройством и маленьким экраном хочется, чтобы приложение было простым и понятным. Поиском баланса между интересами программиста и пользователя мы тут и занимаемся, в общем.

— Это сложно?

— Вообще говоря, непросто. В идеале необходимо уметь разговаривать на одном языке и с пользователями, и с программистами. Если ты пришел из программистов, то, скорее всего, задачи будешь решать так, как они. А если гуманитарий и плохо разбираешься в программировании и технологиях, то заслужить их уважение будет очень непросто. Программисты относятся к людям, которые не умеют программировать, как…

— Ну, то есть у них есть определенный профессиональный снобизм по отношению к пользователям?

— Не то слово! Программисты считают пользователей… ну, недостаточно развитыми существами. Некоторые все же понимают, что простой человек не предназначен для чтения машинного кода. Но не все, не все. Если зайти в AppStore, сразу можно определить, что вот это приложение программист писал для себя — он просто не думал о человеке, не пытался ставить себя на его место.

— То есть между программистом и непрограммистом не так уж много общего?

— В Parallels решаются очень сложные технические задачи — сюда приходят мощные математики и инженеры, у которых мозг, наверное, по-другому работает. Они мыслят категориями сложных технических проблем, решают вопросы эмуляции одной процессорной архитектуры на другую или скрещивания двух разных процессорных архитектур. С миром обычных людей они мало пересекаются. Это не хорошо и не плохо — это по-другому.

О детях

Павел Емельянов, архитектор департамента серверной виртуализации, терпеливо пытается объяснить мне, что это такое:

— Это что-то вроде строительства авианосца, у которого на борту много маленьких виртуальных компьютеров. Мне нужно держать в голове, как все выглядит в системе. И если к этому авианосцу потребуется приделать башню, мне надо будет объяснить разработчикам, как это сделать, чтобы все не перевернулось.

Постичь тонкости виртуализации я так и не смог. Очевидно одно: это очень перспективная технология. Смысл ее в том, чтобы заменить сложное физическое устройство виртуальным.

— Этим занимаются обычные пользователи макбуков: установил себе виртуальную машину, поставил на нее Windows, и теперь у тебя есть и Mac OS, и Windows, — говорит Павел. — Еще виртуализацией пользуются разработчики и крупные компании. Они должны поддерживать IT-инфраструктуру какую-то, а это гораздо проще, когда машина виртуальная, а не железная: ею легче управлять. Железная может сломаться, ее нужно будет из комнаты в комнату носить. С виртуальной проще: запускается она, конечно, на реальной машине, но если с реальной что-то происходит, виртуальную легче перенести в другое место или сохранить. Поэтому большие компании любят виртуализацию.

Ладно, будем считать, что понял.

— А у вас есть ощущение, что вы занимаетесь каким-то особенно важным делом? — спрашиваю слегка невпопад.

— Нельзя сказать, что IT — особо важное дело. Это часть нашей цивилизации. Кто-то занимается железными дорогами, кто-то преподает, кто-то занимается разработкой софта, потому что это неизбежно. Сейчас почти везде стоит какая-нибудь железка, на которой работает какой-то софт. Если перестать его поддерживать, развалится не только он, но и все, что рядом. Но какой-то сверхважности этого всего я не ощущаю.

— Но ведь развалится же все без IT.

— Ну, если железные дороги развалятся, IT тоже сильно пострадает.

— Железнодорожное сообщение постепенно теряет актуальность.

— Но все равно некоторые проблемы авиасообщением не решить. Железные дороги логично заменили гужевой транспорт…

— А IT какую область заменяет?

— Многие. С одной стороны, это развитие автоматизации, то есть уход от ручного труда к автоматизированному. С другой — очередная попытка человека чем-нибудь себя развлечь. В-третьих, IT давно уже полноправный участник научного сообщества. Поэтому сказать, что замещается что-то одно, нельзя.

— Поэтому я и спрашивал про какую-то особую, сакральную важность процесса.

— Ну, это уже вопрос философский. Действительно ли мы хотим идти туда, куда идем? Вы же читали «О дивный новый мир» Хаксли? Хотим ли мы попасть туда? А компьютер, интернет, социальные сети помогают нам двигаться именно в этом направлении.

— То есть вы скептически смотрите на технологический прогресс?

— Любой прогресс может быть использован для позитивных изменений, а может для негативных. Просто увеличивается диапазон возможностей. Как человек будет пользоваться технологиями? Ох… До сих пор, наверное, выдерживается какой-то баланс.

— Мне кажется, что нет. Вот атомная бомба, например, совсем не про баланс. Ее разработчики, наверное, не особо рефлексировали, как будут использованы эти открытия. Вы, кстати, рефлексируете?

— Я рефлексирую. Я занимаюсь деятельностью, очень близкой к науке. Перед любым ученым стоит этот вопрос: к чему приведет его открытие? Вот проникнет он, например, в тайны строения атомного ядра. Во что это может вылиться? Может, в технологию холодного ядерного синтеза, это прорыв в энергетике, а может, в еще более мощную ядерную бомбу. Так же и в IT. Вот сделаем мы сейчас более совершенный алгоритм для подбора контрольных сумм. Они активно используются в криптографии. Если взломать этот алгоритм, то можно разрушить огромное количество криптографических защит: от банального подбора паролей до чтения международной сверхсекретной переписки. И вот кто-то разгадает эту загадку — с одной стороны, прорыв в математике, да и физикам пригодится, с другой стороны, неизвестно, кто и чьи пароли будет взламывать с помощью этих знаний. Встает вопрос: заниматься этим или не заниматься? Может, все же нет? Но если такой ответ дадут все, развитие остановится. Как сделать так, чтобы человек разумно пользовался плодами прогресса? Воспитывать с детства, наверное…

— То есть вы технооптимист?

— Оптимист, но, видимо, вынужденный. У меня четверо детей. И если я смогу убедить себя, что все движется в худшем направлении, то зачем я рожаю детей? Поэтому я стараюсь смотреть на вещи более позитивно.

— А вы как родитель чувствуете, что сегодняшний ребенок — это вообще какой-то новый человек, который компьютером учится пользоваться иногда раньше, чем осваивает речь?

— Конечно, чувствую, но не на примере своих детей. У нас дома гаджета всего три: ноутбук, мой телефон и телефон старшего. Ему девять, и недавно мы купили ему телефон, потому что он уже требует самостоятельности какой-то. Мы особо не форсируем это дело.

— Сознательно?

— Да. Порой даже взрослому человеку тяжело справиться со всем этим, а ребенку еще тяжелее: он погружается туда и отгораживается от внешнего мира, потому что красивые картинки, все блестит, звучит, а дети на это очень падки. Я как-то в зале ожидания наблюдал за двумя друзьями лет пяти-шести. Их семьи вместе летели, видимо. Каждый погружался в свой планшет на полчаса, что-то там делал, играл, потом они обнаруживали друг друга и начинали бегать и прыгать. Но через пять минут им надоедало гоняться друг за дружкой — они просто не могли дольше находиться вместе и кидались обратно к своим планшетам еще на полчаса. Без социализации при таком количестве технических достижений будет очень тяжело. Когда человек замыкается на своих мыслях, очень легко потерять чувство реальности.

Неожиданно к нам в переговорную входят двое:

— А у нас тут митинг! — говорит один.

Мы с Павлом отправляемся на поиски новой переговорной. Следственный комитет может расслабиться: митингами в Parallels называют совещания. Все переговорные заняты, люди активно митингуют.

— А я думал, все внутреннее общение происходит в чатах и по почте.

— Есть вещи, которые можно обсудить по почте, есть такие, которые нужно обсуждать голосом и при этом иногда еще видеть, как человек размахивает руками. А есть вещи, которые можно обсуждать только друг с другом. Большая часть информации передается невербально.

— Но человек будущего что-то с этим сделает?

— Что-то сделает. Мне кажется, технологии будут работать на то, чтобы создать ощущение, будто мы сидим рядом во время удаленного общения. Но это напоминает мне асимптоту: мы будем вечно приближаться к этому, но никогда не достигнем. Встречаться все равно придется.

Об антиутопии

Анна Мелехова разработчик, преподает в Физтехе, в честь нее названа внутрикорпоративная единица продуктивности: одна Тетя Аня равна внушительному количеству строчек кода.

Обсуждаем будущее:

— Раньше все люди, которые пользовались DOS, обязаны были хоть примерно представлять себе, как устроены компьютерные технологии, — Анна рассуждает о компьютерах и операционных системах вдохновенно, как о творчестве Пастернака. — Сейчас те, кто пользуется айпадом, не обязаны даже представлять, что вообще это компьютер. Расслоение на почве понимания технологий, конечно, будет усиливаться. А теперь представьте себе, что в какой-то момент все люди, обладающие этим знанием, как-нибудь некрасиво умрут. И что тогда будет? Вот у Жюля Верна в «Таинственном острове» инженер прилетел на остров и то сделал, это сделал, чуть ли не дизельный двигатель построил из подручных материалов. А сегодня мы очень сильно специализируемся…

— И дизельный двигатель из кокосовой шелухи уже не соберем.

— Но и заставлять наших мам и бабушек знать, что айпад — это компьютер, тоже излишне. Свободное время лучше тратить на какие-нибудь возвышенные, философские материи.

— Чем дальше развиваются технологии, тем меньше простой пользователь понимает, каким образом работает эта тоненькая фигня, — кручу я в руке смартфон. — Мне кажется, формируется какой-то околомагический культ, в котором производители технологий становятся приближенными к знанию адептами, а потребители — рядовыми последователями секты.

— На магический культ это, безусловно, похоже. Цивилизация развивается циклически, и на каждой итерации цикла происходит какое-то расслоение. Раньше оно было связано с недоступностью знания: многие просто не умели читать. Но в тот момент, когда информация стала полностью доступна, люди потеряли к ней интерес. Это как у Хаксли. Когда я прочитала «О дивный новый мир», то удивилась: ну как он узнал, что все так будет? Оруэлл говорил, что правду будут скрывать, историю переписывать. А тут не надо ничего скрывать, вокруг столько информации, что ты в ней просто тонешь. Возникает вопрос: можно ли приблизиться к адептам технологического знания? Наверное, можно. Какова вероятность, что ты это сделаешь? Меньше, чем тогда, когда информации было не так много. Потому что возможностей, в том числе и мусорных, было меньше.

Анна говорит, что главный человек будущего не просто программист, а программист с архитектурным мышлением:

— Системы становятся все более сложными, и в будущем произойдет очень серьезное разделение. Каждый специалист будет работать над своим кусочком, как терпеливый муравей, который несет соломинку. И только те, кто представляет общую архитектуру системы, окажутся на коне.

— То есть знание станет главным критерием социального расслоения?

— Да. Вскоре у нас, как у Гессе, будут университеты, в которых только избранные будут что-то знать. Сильное расслоение, облачные технологии — все это приметы нашего общества, и с этим надо как-то жить.

— Но вы же понимаете, что это не совсем гуманное общество? Чем совершеннее технологии и выше автоматизация труда, тем больше индусов, которые собирают на конвейере наши телефоны, лишаются работы.

— Есть какие-то вещи, которые не стоит полностью автоматизировать: сфера услуг, сельское хозяйство, ремесла какие-то. Вы ведь любите вещи ручной работы — глиняные, деревянные? Вот пусть индусы возвращаются в область ручного труда — это же прекрасно! И они будут счастливее, и мы.

***

Я покидаю офис Parallels и плутаю между одинаковыми многоэтажками в бетонном брюхе Отрадного. Жара размазывает по асфальту, местные жители пытаются найти тень. В одном из прохладных переулков два аборигена в спортивных костюмах пытаются выяснить, кто я по жизни, и отжать у меня телефон. Я долго молчу, пытаясь сформулировать мысль, что по жизни я, видимо, индус, непоправимо далекий от технологического культа, что делает мои перспективы не особо завидными. Двое решают, что я не в себе, и разочарованно отворачиваются.

Когда-нибудь экономика знаний, несомненно, победит.

Программирование в Unity для опытных программистов C# и C++

Традиционная модель «игровой объект — компонент» хорошо работает и сегодня, поскольку она проста как для программистов, так и других пользователей, а также удобна для создания интуитивных интерфейсов. Добавите компонент Rigidbody к объекту GameObject — он начнет падать, добавите компонент Light — GameObject начнет излучать свет. Все остальное также подчиняется этой простой логике. 

При этом система компонентов создана на основе объектно-ориентированной платформы, что создает сложности для разработчиков при работе с кэшем и памятью развивающегося оборудования.  

Компоненты и игровые объекты относятся к «тяжелым объектам C++». Все объекты GameObject имеют имя. Их компоненты представляют собой оболочки для C# поверх компонентов на C++. Это упрощает работу с ними, но может влиять на производительность, если они будут храниться в памяти без явной структуры. Объект C# может находиться на любом участке памяти. Объект C++ также может находиться в любом участке памяти. Группировка и последовательное размещение объектов в памяти отсутствуют. При каждой загрузке в центральный процессор для обработки объект приходится собирать по частям из разных участков памяти. Это может сильно замедлить загрузку, а оптимизация потребует много усилий.

Для решения этих проблем мы начали перерабатывать базовые системы Unity на основе высокопроизводительного, многопоточного стека информационно-ориентированных технологий или DOTS (в настоящее время в статусе предварительной версии). 

DOTS позволяет вашей игре эффективно использовать все возможности новейших многоядерных процессоров. Стек состоит из следующих компонентов: 

  • система задач C# для эффективного исполнения кода на многопоточных системах;
  • Entity Component System (ECS) для разработки высокопроизводительного кода по умолчанию;
  • компилятор Burst для компиляции скриптов в оптимизированный нативный код.

ECS — это новая система компонентов в составе DOTS; все традиционные объектно-ориентированные манипуляции над GameObject отражаются на экземпляре в новой системе. Название «Компонент» никак не изменилось. Важнейшее отличие — в структуре данных. Подробнее об этом можно узнать из статьи «О DOTS: Entity Component System».

Все инженеры умеют программировать, но не все программисты могут быть инженерами: в чем отличие?

Многим людям не нравится термин “инженер по разработке программного обеспечения” из-за относительного сравнения с инженерным делом. Но эта статья посвящена не термину. Если вам не нравится название, вы можете заменить его на “автор ПО”, “мастер ПО” или даже “художник по ПО”.

Под инженером по разработке я подразумеваю человека, который считает создание качественных программ своей профессией. Человек, который применяет науку и статистику в своей профессии и не смотрит на это как на работу, которая просто приносит деньги.

Знание программирования не делает вас инженером. Любой может научиться программировать. Любой может создать простые программы, которые будут работать для него на собственном компьютере, но это не гарантирует, что те же программы будут работать для остальных.

Моя любимая аналогия — любой человек может петь для себя в душе, но на вечеринке вы не будете ставить свои записи. Вы полагаетесь на профессионалов.

Хотите еще бльше аналогий? Конечно:

  • Мы изучаем математику и правописание в школе, но это не делает нас математиками и авторами.
  • Многие могут научиться готовить, но, чтобы накормить много людей, мы зовем повара.
  • Вы не будете звать соседа с инструментами, чтобы построить дом с нуля.

Я хочу донести мысль о том, что простые программы отличаются от тех, что создали инженеры. Программирование — это создание инструкций для компьютеров, чтобы они приняли входные данные и превратили их в определенный результат.

Процесс проектирования программ — это планирование, написание, тестирование и поддержка компьютерных программ с целью решения проблемы для многих пользователей. Это создание надежных решений, которые выдержат проверку временем и будут работать не только с очевидными проблемами, но и с неизвестными.

Инженеры понимают все о проблемах, которые они решают, о своих решениях, об ограничениях этих решений, последствиях этих решений для приватности и безопасности.

Если человек не понимает проблему, он или она не может создать решение для нее.

Склонность к поиску решений

Инженеры не считают свою деятельность просто написанием программ. Они думают о потребностях и решениях проблем. Это важно, потому что не каждая проблем нуждается в новой программе. Некоторые проблемы можно решить уже существующими программами. Некоторые проблемы можно вообще предотвратить, если действовать заранее. Создание хороших программ часто включает предотвращение будущих проблем.

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

Перед созданием программы инженер задает вопросы:

  • Какие проблемы я пытаюсь решить?
  • Можно ли сделать для их решения что-то, кроме написания кода?
  • Что я могу сделать, чтобы эти проблемы было проще решить при помощи кода?

Качество кода

Отличные программы понятны, и их можно легко расширить, они отлично работают с другими программами, а поддерживать их не так сложно. Качеством кода нельзя жертвовать, а использовать временные решения из-за дедлайна или эмоций — неприемлемо.

Один из самых важных аспектов разработки ПО — создавать с самого начала системы, которые можно будет расширять. Изменение программ неизбежно. Пользователи начнут требовать новых функций и новых способов применения программ.

Сама по себе программа не так полезна. Ценность их функций проявляется, когда разные программы коммуницируют друг с другом, обмениваются данными и совместно работают над представлением данных и интерфейсов пользователям. Об этом нужно помнить при создании программ. Какие сообщения они будут принимать? Какие события будут отслеживаться? Какие сообщения они будут отправлять? Как мы будем проводить аутентификацию и авторизацию коммуникаций?

Другой важный аспект отличных программ — это ясность кода, а не количество тестов или число в отчете по тестовому покрытию. Этот код может прочитать кто-то ещё? Смогу ли я понять этот код через несколько недель?

В программировании существует только две по-настоящему сложных вещи: инвалидация кэша и именование переменных, — Фил Карлтон

Удобство чтения кода важнее, чем вы думаете. К сожалению, для ясности кода нет хороших метрик. Знание хороших методов может помочь, но часто этого недостаточно. Хорошие инженеры просто учатся этому с опытом. Здесь подходит метафора с писательством: знание большого количества слов не поможет вам писать понятные тексты.

“У меня не было времени на короткое письмо, поэтому я написал длинное”, — Марк Твен

В программах случаются ошибки. Возможность без проблем исправить их — это ключевой атрибут хорошей программы. Ошибки должны сопровождаться понятными сообщениями и храниться в одном месте. Когда появляется отчет о новой ошибке, ответственный за исправление человек должен иметь возможность устранить в ней баги. Он или она должны иметь возможность зайти в систему и прочитать информацию об ошибке в любое время. У них должна быть возможность подтвердить ожидания о любой части системы.

Среда и тестирование

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

Программное обеспечение для браузера должно работать во всех популярных браузерах. Программы для компьютеров должны работать для пользователей Mac и Windows. Приложения для работы с данными должны работать, когда подключение слишком медленное или его совсем нет.

Чтобы написать программу, инженеры должны продумать любой возможный сценарий и спланировать тестирование всех этих сценариев. Это начинается со “счастливого пути”, когда ничего неожиданного не происходит, но затем инженеры должны прописать каждую проблему, которая может случиться, и написать для них тесты. Некоторые инженеры начинают с написания тест-кейсов, которые симулируют эти сценарии. Затем они пишут код, который проходит все эти тесты.

Инженеры понимают расплывчатые требования программ. Уникальный навык инженера — это не просто знать, как написать решение, но понять, что должно быть в этом решении.

Стоимость и эффективность

Во многих случаях инженеры могут решить проблемы быстро. Если вы думаете, что найм опытных программистов повысит расходы, подумайте еще раз. Чем больше у программиста опыта, тем быстрее он или она сможет создать надежное решение, которое можно будет поддерживать без особых трудностей. Это означает сокращение расходов в долгосрочной перспективе.

Вам также нужно принять во внимание стоимость запуска программы. Каждая программа будет использовать компьютерные ресурсы, которые не бесплатны. Инженеры будут писать эффективные программы, которые не будут тратить компьютерные ресурсы впустую. Например, это кэширование часто используемых данных, но это только одно из тысяч решений, которые могут сделать программу быстрее и эффективнее.

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

Удобство использования

Хорошие программы создаются с учетом пользовательского опыта. Взаимодействие человека и компьютера — это большая тема с многочисленными исследованиями и выводами. Чем чаще будут учитываться эти выводы, тем лучше будут программы.

Вот несколько примеров:

  • При создании форм для ввода данных хорошая программа будет игнорировать прописные или строчные буквы? которые используются для ввода email-адреса. Она также уберет ненужные пробелы. Не нужно мучать пользователя из-за включенного Caps Lock, адрес почты уникален. Если программа принимает новые адреса, она должна сообщать пользователю о проблемах с вводом, например, об отсутствии знака @ или опечатке в gmail.ocm.
  • При перенаправлении пользователя хорошая программа запомнит первоначальное местоположение и перенаправит пользователя туда после завершения задачи. Хорошая программа также запомнит уже введенные данные и взаимодействия, которые нужны будут в следующих шагах. Например, вы ищете авиабилеты на Expedia в качестве гостя. Затем вы решили создать аккаунт. Вся ваша история поиска будет сохранена в новый аккаунт, и вы сможете получить к ней доступ с разных устройств.
  • Хорошая программа создается с учетом пользовательских сценариев. Поставьте себя на место пользователя. Однажды я забронировал билет United и забыл ввести свой номер постоянного пассажира. После получения подтверждения я отправился на сайт United, чтобы добавить номер, и эта задача заняла у меня десять минут. К этой функции не было очевидных путей, поэтому мне пришлось проверить все ссылки, которые могли бы вести к ней. Я уже был на странице с этой функцией, но я не увидел её в первый раз, потому что она была спрятана в большой форме. Мне пришлось найти информацию о пассажире, пролистать около 20 строк в этой форме, ввести номер пассажира и номер телефона, чтобы отправить эту форму. Это пример программы, которая создавалась без учета точки зрения пользователя.

Читабельность и безопасность

Это наиболее важные моменты, которые отличают профессионалов от любителей. Они знают, что ответственны за создание надежных и безопасных решений.

Программа должна быть устойчивой к плохим входным данным, состояниям и взаимодействиям. Этого очень сложно достичь, и поэтому мы слышим о том, что люди погибают из-за ошибок в ПО.

Пользователи будут вводить неверные данные в программу. Некоторые будут делать это специально, чтобы взломать её. Ответственного за недавний скандал с Equifax обвинили в том, что этот человек не сделал свою работу, то есть не создал устойчивую к зловредным входным данным программу.

Безопасность касается не только зловредных данных, но и обычных. Если пользователь забывает пароль, то сколько раз он или она сможет его ввести? Заблокируете ли вы после этого аккаунт? Что если кто-то этого и добивается? Позволите ли вы вводить пароль через незащищенное соединение? Что если попытка логина состоялась из необычного места? Что если логин кажется сгенерированным автоматически?

Что вы сделаете, чтобы защитить пользователей от межсайтового скриптинга и подделки запросов, атаки посредника и простого социального фишинга? Есть ли у вас стратегия на случай DDoS-атаки? Эти вопросы — это только несколько из проблем, к которым вы должны готовиться.

Безопасные программы не хранят чувствительную информацию в форме простого текста, а в виде зашифрованных данных, которые сложно взломать. Это запасная стратегия на случай взлома. В программах будут случаться ошибки, и если вы об этом не знаете или вы не подготовлены, то вас нельзя считать профессионалом.

Дефекты программ невидимы. Наша способность предсказывать и предотвращать известные дефекты ограничена. Поэтому инженеры понимать ценность хороших инструментов, которые могут помочь им писать корректные и безопасные программы.

Инструменты

Несомненно, нам нужны хорошие инструменты. Они многое меняют и часто недооцениваются. Представьте, если бы нам все ещё нужны были FTP для файлов! Представьте проблемы с производительностью и устранением багов без Chrome DevTools! Представьте, как неэффективно бы было писать на JavaScript без ESLint и Prettier!

Любой инструмент, который сокращает цикл обратной связи, должен быть ценным дополнением. Аргумент Брета Виктора об изобретении мгновенной визуальной репрезентации того, что мы создаем, открыл мне глаза. Принятие и улучшение инструментов — это единственный способ попасть в это светлое будущее.

Когда я нахожу отличный инструмент, я жалею лишь о том, что не нашел его раньше. Хорошие инструменты помогут вам стать хорошим программистом. Ищите их, используйте их, цените их и улучшайте их.

Выбор языка имеет значение. Типобезопасность имеет значение. Лучшее, что случилось с JavaScript — это TypeScript и Flow. Статический анализ кода важнее, чем вы думаете. Если вы этого не делаете, то ставите себя под удар неизвестных будущих проблем. Не программируйте без системы статической проверки типов. Если в вашем языке этого нет, поменяйте язык или используйте компилятор. Сегодняшние компиляторы могут работать, просто читая комментарии в коде, и это будущее проверки типов для языков, которые не поддерживают её.

Эволюция разработки

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

Разработка не для каждого, но все должны учиться решать свои проблемы с компьютерами. Если вы можете научиться писать простые программы, то стоит это сделать. Если вы можете научиться использовать сервисы, то стоит это сделать. Знание программ с открытым исходным кодом даст вам много возможностей.

Проблемы эволюционируют, и разработка должна развиваться аналогично. Будущее этой профессии — позволить обычным пользователям использовать свои компьютеры без необходимости учиться пять лет. Дайте пользователям возможность решать простые проблемы простыми инструментами. Инженеры должны создавать хорошие инструменты, решать большие проблемы и пытаться предотвращать неизвестные.

Источник

Если вы нашли опечатку – выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать [email protected].

Введение в серверную часть – Изучение веб-разработки

Добро пожаловать на курс для начинающих по программированию серверной части сайта! В этой первой статье мы рассмотрим программирование на стороне сервера с высокого уровня, отвечая на такие вопросы, как «что это»?, «как это отличается от программирования на стороне клиента»? и «почему это так полезно»? После прочтения этой статьи вы поймёте дополнительные возможности, доступные веб-сайтам посредством программирования на стороне сервера.

Перед стартом:Базовая компьютерная грамотность. Базовое понимание, что такое веб-сервер.
Цель:Ознакомиться с тем, что такое программирование серверной части, на что оно способно и чем отличается от программирования клиентской части.

Большинство крупных веб-сайтов используют программирование серверной части чтобы динамично отображать различные данные при необходимости, в основном взятые из базы данных, располагающейся на сервере и отправляемые клиенту для отображения через некоторый код (например, HTML и JavaScript).

Возможно, самая значительная польза программирования серверной части в том, что оно позволяет формировать контент веб-сайта под конкретного пользователя. Динамические сайты могут выделять контент, который более актуален в зависимости от предпочтений и привычек пользователя. Это также может упростить использование сайтов за счёт сохранения личных предпочтений и информации, например, повторного использования сохранённых данных кредитной карты для оптимизации последующих платежей.

Это также даёт возможность взаимодействовать с пользователем сайта, посылая уведомления и обновления по электронной почте или по другим каналам. Все эти возможности позволяют глубже взаимодействовать с пользователями.

В современном мире веб-разработки настоятельно рекомендуется узнать о разработке на стороне сервера.

Веб-браузеры взаимодействуют с веб-серверами при помощи гипертекстового транспортного протокола (HTTP). Когда вы нажимаете на ссылку на веб-странице, заполняете форму или запускаете поиск,  HTTP-запрос  отправляется из вашего браузера на целевой сервер.

Запрос включает в себя URL, определяющий затронутый ресурс, метод, определяющий требуемое действие (например, получить, удалить или опубликовать ресурс) и может включать дополнительную информацию, закодированную в параметрах URL (пары поле-значение, оправленные как строка запроса), как POST запрос (данные, отправленные методом HTTP POST) или в куки-файлах.

Веб-серверы ожидают сообщений с клиентскими запросами, обрабатывают их по прибытию и отвечают веб-браузеру при помощи ответного HTTP сообщения (HTTP-ответ). Ответ содержит строку состояния, показывающую, был ли запрос успешным или нет (например, «HTTP/1.1 200 OK» в случае успеха).

Тело успешного ответа на запрос может содержать запрашиваемые данные (например, новую HTML-страницу или изображение, и т. п.), который может отображаться через веб-браузер.

Статические сайты

Схема ниже показывает базовую архитектуру веб-сервера для статического сайта (статический сайт — это тот, который возвращает одно и то же жёстко закодированное содержимое с сервера всякий раз, когда запрашивается конкретный ресурс). Когда пользователь хочет перейти на страницу, браузер отправляет HTTP-запрос «GET» с указанием его URL. 

Сервер извлекает запрошенный документ из своей файловой системы и возвращает HTTP-ответ, содержащий документ и успешный статус (обычно 200 OK). Если файл не может быть извлечён по каким-либо причинам, возвращается статус ошибки (смотри ошибки клиента и ошибки сервера).

Динамические сайты

Динамический веб-сайт — это тот, где часть содержимого ответа генерируется динамически только при необходимости. На динамическом веб-сайте HTML-страницы обычно создаются путём вставки данных из базы данных в заполнители в HTML-шаблонах (это гораздо более эффективный способ хранения большого количества контента, чем использование статических сайтов).

Динамический сайт может возвращать разные данные для URL-адреса на основе информации, предоставленной пользователем или сохранёнными настройками, и может выполнять другие операции, как часть возврата ответа (например, отправку уведомлений).

Большая часть кода для поддержки динамического веб-сайта должна выполняться на сервере. Создание этого кода известно, как «программирование серверной части» (или иногда «программирование бэкенда»).

Схема ниже показывает простую архитектуру динамического сайта. Как и на предыдущей схеме, браузеры отправляют HTTP-запросы на сервер, затем сервер обрабатывает запросы и возвращает соответствующие HTTP-ответы.

Запросы статических ресурсов обрабатываются так же, как и для статических сайтов (статические ресурсы — это любые файлы, которые не меняются, обычно это: CSS, JavaScript, изображения, предварительно созданные PDF-файлы и прочее).

Запросы динамических данных отправляются (2) в код серверной части (показано на диаграмме как Веб-приложение). Для «динамических запросов» сервер интерпретирует запрос, читает необходимую информацию из базы данных (3), комбинирует извлечённые данные с шаблонами HTML и возвращает ответ, содержащий сгенерированный HTML (5, 6).

Теперь обратим внимание на код, задействованный в серверной части и клиентской части. В каждом случае код существенно различается:

  • Они имеют различные цели и назначение.
  • Как правило, они не используют одни и те же языки программирования (исключение составляет JavaScript, который можно использовать на стороне сервера и клиента).
  • Они выполняются в разных средах операционной системы.

Код, который выполняется в браузере, известный как код клиентской части, прежде всего связан с улучшением внешнего вида и поведения отображаемой веб-страницы. Это включает в себя выбор и стилизацию компонентов пользовательского интерфейса, создание макетов, навигацию, проверку форм и т. д. Напротив, программирование веб-сайта на стороне сервера в основном включает выбор содержимого, которое возвращается браузеру в ответ на запросы. Код на стороне сервера обрабатывает такие задачи, как проверка отправленных данных и запросов, использование баз данных для хранения и извлечения данных и отправка правильных данных клиенту по мере необходимости.

Код клиентской части написан с использованием HTML, CSS и JavaScript — он запускается в веб-браузере и практически не имеет доступа к базовой операционной системе (включая ограниченный доступ к файловой системе).

Веб-разработчики не могут контролировать, какой браузер может использовать каждый пользователь для просмотра веб-сайта — браузеры обеспечивают противоречивые уровни совместимости с функциями кода на стороне клиента, и одной из задач программирования на стороне клиента является изящная обработка различий в поддержке браузера.

Код серверной части может быть написан на любом количестве языков программирования — примеры популярных языков серверной части включают в себя PHP, Python, Ruby, C# и NodeJS (JavaScript). Код серверной части имеет полный доступ к операционной системе сервера, и разработчик может выбрать какой язык программирования (и какую версию) он хотел бы использовать.

Разработчики обычно пишут свой код, используя веб-фреймворки. Веб-фреймворки — это наборы функций, объектов, правил и других конструкций кода, предназначенных для решения общих проблем, ускорения разработки и упрощения различных типов задач, стоящих в конкретной области.

И снова, поскольку и клиентская и серверная части используют фреймворки, области очень разные и, следовательно, фреймворки тоже разные. Фреймворки клиентской части упрощают вёрстку и представление данных, тогда как фреймворки серверной части обеспечивают много «обычной» функциональности веб-сервера, которую вы, возможно, в противном случае, должны были осуществлять самостоятельно (например, поддержка сессий, поддержка пользователей и аутентификация, простой доступ к базе данных, шаблонам библиотек и т. д.).

На заметку: Фреймворки клиентской части часто используются для ускорения написания кода клиентской части, но вы также можете решить писать весь код руками; на самом деле, написание кода руками может быть более быстрым и эффективным, если вам нужен небольшой простой веб-сайт UI.

И, наоборот, вы практически никогда не посмотрите в сторону написания кода серверной части веб-приложения без фреймворка: осуществление жизненно важной функции, такой как HTTP сервер действительно сложно сделать с нуля, скажем, на Python, но веб-фреймворки для Python, такие как Django, обеспечивают это из коробки наряду с другими полезными инструментами.

Что можно сделать в серверной части?

Программирование серверной части очень полезно поскольку позволяет эффективно доставлять информацию, составленную для индивидуальных пользователей и, таким образом, создавать намного лучший опыт использования.

Компании, такие как Amazon, используют программирование серверной части для построения исследовательских результатов для товаров, формирования целевого предложения, основанного на предпочтениях клиента и предыдущих покупках, упрощения заказов и т. д. Банки используют программирование серверной части, чтобы хранить учётную информацию и позволять только авторизованным пользователям просматривать и совершать транзакции. Другие сервисы, такие как Facebook, Twitter, Instagram и Wikipedia используют бэкенд, чтобы выделять, распространять и контролировать доступ к интересному контенту.

Некоторые типичные применения и выгоды бэкенда перечислены ниже. Вы заметите, что есть некоторое пересечение!

Эффективное хранение и доставка информации

Представьте, сколько товаров доступно на Amazon, и представьте, сколько постов было написано на Facebook? Создание статической страницы для каждого товара или поста было бы абсолютно неэффективным.

Программирование серверной части позволяет вместо этого хранить информацию в базе данных и динамически создавать и возвращать HTML и другие типы файлов (например, PDF, изображения, и т. д.). Также есть возможность просто вернуть данные (JSON, XML, и т. д.) для отображения, используя подходящий фреймворк клиентской части (это уменьшает загрузку процессора на сервере и количество передаваемых данных).

Сервер не ограничен в отправке информации из баз данных и может вместо этого возвращать результат инструментов программного обеспечения или данные из сервисов коммуникации. Контент даже может быть целевым относительно устройства клиента, который его получает.

Из-за того, что информация находится в базе данных, её также можно легко передать и обновить через другие бизнес системы (например, отслеживание).

На заметку: вам не нужно сильно напрягать своё воображение, чтобы увидеть достоинства кода серверной части для эффективного хранения и передачи информации:

  1. Зайдите на Amazon или в другой интернет-магазин.
  2. Введите в поиск несколько ключевых слов и заметьте, как структура страницы не изменилась, тогда как результаты изменились.
  3. Откройте два или три разных товара. Заметьте, что они имеют схожую структуру и внешний вид, но содержимое для разных товаров было вставлено из базы данных.

Для обычного поиска (например, «рыба») вы можете увидеть буквально миллионы найденных значений. Использование базы данных позволяет им храниться и передаваться эффективно, и это позволяет контролировать представление информации всего в одном месте.

Настраиваемый пользовательский опыт взаимодействия

Серверы могут хранить и использовать информацию о клиентах чтобы поставлять удобный и сделанный индивидуально пользовательский опыт взаимодействия. Например, многие сайты хранят данные кредитных карт, чтобы не нужно было вводить их повторно. Сайты, наподобие Google Maps, могут использовать сохранённое и текущее местоположение для предоставления информации о маршруте, а также историю поиска или путешествий для выделения местных предприятий в результатах поиска.

Более глубокий анализ привычек пользователя может быть использован для прогнозирования их интересов и дальнейших настроек ответов и уведомлений, например, предоставление списка ранее посещённых популярных мест, которые вы, возможно, захотите найти на карте.

На заметку: Google Maps сохраняет вашу историю поиска и посещений. Часто посещаемые или часто вводимые в поиск локации выделяются больше, чем остальные.

Результаты поиска Google оптимизируются на основе предыдущего поиска.

  1.  Перейдите в поиск Google.
  2.  Произведите поиск по слову «футбол».
  3.  Теперь попробуйте ввести «любимое» в поисковой строке и понаблюдайте, как работают подсказки автозаполнения поиска.

Стечение обстоятельств? Нет!

Контролируемый доступ к контенту

Программирование серверной части позволяет сайтам ограничивать доступ авторизованным пользователям и предоставлять только ту информацию, которую пользователю разрешено видеть.

Реальные примеры:

  • Социальные сети, такие как Facebook, позволяют пользователям полностью контролировать свои данные, но только своим друзьям разрешать просматривать или комментировать их. Пользователь определяет, кто может просматривать его данные и, более того, чьи данные появляются на его стене. Авторизация — центральная часть опыта взаимодействия.
  • Сайт, на котором вы находитесь прямо сейчас, контролирует доступ к контенту: статьи видны всем, но только авторизованные пользователи могут редактировать контент. Чтобы проверить это, нажмите на кнопку «Редактировать» в верхней части страницы, и, если вы авторизованы, вы увидите редакторский интерфейс, а если нет — вас перенаправит на страницу авторизации.

На заметку: Рассмотрим другие реальные примеры, где доступ к контенту контролируется. Например, что вы можете увидеть, если зайдёте на сайт вашего банка? Авторизуйтесь через вашу учётную запись, и какую дополнительную информацию вы можете просматривать и редактировать? Что за информацию вы можете увидеть, которую может редактировать только банк?

Хранение информации о сессии/состоянии

Программирование серверной части позволяет разработчикам использовать сессии – изначально это механизм, позволяющий серверу хранить информацию о текущем пользователе сайта и отправлять разные ответы, основанные на этой информации.

Это позволяет, например, сайту знать, что пользователь был предварительно авторизован и выводить ссылки на его адрес электронной почты или историю заказов или, возможно, сохранить прогресс простой игры, так чтобы пользователь мог вернуться на сайт продолжить с того места, где он закончил.

На заметку: Посетите новостной сайт, у которого есть подписка и откройте ветку тегов (например, The Age). Продолжайте посещать сайт в течение нескольких часов/дней. В итоге вас начнёт перенаправлять на страницы, объясняющие, как оформить платную подписку, а сами статьи станут вам недоступны. Эта информация является примером сессии, сохранённой в куки-файлах.

Уведомления и средства связи

Серверы могут отправлять общие или пользовательские уведомления непосредственно через сайт или по электронной почте, через смс, мгновенные сообщения, видеосвязь или другие средства связи.

Вот несколько примеров:

  • Facebook или Twitter отправляет уведомления по электронной почте и смс-сообщения, чтобы уведомить вас о новых разговорах.
  • Amazon регулярно отправляет письма на электронную почту, предлагающие товары, похожие на те, которые уже были куплены или просматривались вами, которые могут вас заинтересовать.
  • Веб-сервер может посылать сообщения администратору сайта, предупреждая его о том, что на сервере заканчивается память или о подозрительной активности пользователя.

На заметку: Самый распространённый вид уведомлений – это «подтверждение регистрации». Возьмите почти любой интересующий вас крупный сайт (Google, Amazon, Instagram и т. п.) и создайте новую учётную запись, используя ваш адрес электронной почты. Вскоре вы получите письмо, подтверждающее факт вашей регистрации или содержащее информацию о необходимости активировать вашу учётную запись.

Анализ данных

Веб-сайт может собирать много данных о своих пользователях: что они ищут, что они покупают, что они рекомендуют, как долго они остаются на каждой странице. Программирование серверной части может быть использовано, чтобы усовершенствовать ответы, основанные на анализе этих данных.

Например, и Amazon, и Google рекламируют товары на основании предыдущих поисков (и покупок).

На заметку: Если вы пользуетесь Facebook, зайдите на вашу стену и посмотрите на ряд постов. Заметьте, что некоторые посты не идут по порядку: в частности, посты с большим количеством «лайков» часто находятся выше по списку, чем остальные. Также взгляните на рекламу, которую вам показывают, вы вероятно увидите рекламу товаров, которые искали на других сайтах. Алгоритм Facebook для выделения контента и рекламы может казаться мистикой, но очевидно, что он зависит от ваших лайков и запросов поиска!

Поздравляем, вы дошли до конца первой статьи о программировании серверной части.

Теперь вы узнали, что код серверной части выполняется на веб-сервере и его основная роль состоит в контролировании отправляемой пользователю информации (тогда как код клиентской части в основном определяет структуру и способ преподнесения информации пользователю). Вы должны также понимать, что это полезно, так как позволяет создавать веб-сайты, которые эффективно доставляют информацию, собранную для конкретных пользователей и иметь чёткое представление о некоторых вещах, которые вы сможете делать, когда станете разработчиком бэкенда.

Наконец, вы должны понимать, что код серверной части может быть написан на разных языках программирования, и что вам следует использовать веб-фреймворк для упрощения процесса написания кода.

В следующей статье мы поможем вам выбрать лучший фреймворк для вашего первого сайта; затем мы изучим несколько основных взаимодействий с клиентской частью более подробно.

CoDeSys – повседневный инструмент программиста ПЛК | Издательский Дом “ИнфоАвтоматизация”

Представлены архитектура, основные особенности и возможности многофункционального программного комплекса, предназначенного для решения задач промышленной автоматизации, CoDeSys V3, названы наиболее важные и новые его компоненты.

На сегодняшний день CoDeSys (Controller Development System) – это самый популярный в мире аппаратно независимый комплекс для прикладного программирования ПЛК и встраиваемых контроллеров. Основным его компонентом является среда программирования на языках стандарта МЭК 61131-3. Комплекс работает на компьютере. Программы компилируются в машинный код и загружаются в контроллер. Любую задачу, которая имеет решение в виде программы, можно реализовать в CoDeSys.

Назначение и области применения CoDeSys

Изначально CoDeSys был нацелен на задачи, требующие автономности, надежности и предельного быстродействия при минимизации аппаратных средств. Благодаря этому он вышел далеко за рамки традиционных для МЭК 61131-3 систем ПЛК. Сегодня автомобили, краны, экскаваторы, самосвалы, яхты, печатные машины, деревообрабатывающие станки, литейные и прокатные машины, сборочные автоматы крупнейших мировых брендов включают один или группу встроенных контроллеров с CoDeSys. Компанией ITQ GmbH в 2011 г. было проведено исследование характеристик и распространенности программных инструментов в областях машиностроения и мобильных применений в Европе [1]. По его результатам, CoDeSys и инструменты на его базе (Bosh Rexroth IndraWorks, Beckhoff TwinCAT и др) используют 36% компаний. Конкурирующие с CoDeSys универсальные инструменты совместно составили 7%.

На сегодняшний день CoDeSys успешно применяется во всех без исключения областях промышленности. В мире более 350 компаний, изготавливают контроллеры с CoDeSys в качестве штатного инструмента программирования. За 2011 г. продано 500 тыс. лицензий на различные устройства с CoDeSys. Все конкурирующие системы отстают в разы, что позволяет доказательно говорить о мировом лидерстве.

Как продукт, CoDeSys ориентирован на изготовителей контроллеров. Разрабатывая новый контроллер, они устанавливают в него систему исполнения CoDeSys Control. Собирают из ее компонентов требуемую конфигурацию, добавляют собственные ноу-хау и специфические компоненты и получают собственное инструментальное ПО. Как правило, к пользователю CoDeSys попадает в коробке вместе с оборудованием. Ему нужно только установить систему и перейти к решению своих практических задач. Все коммерческие и технические вопросы, связанные с поддержкой ядра контроллера, всех типов его аппаратных модулей, библиотек, стеков и конфигураторов сетей его беспокоить не должны. Все это должно быть решено за него разработчиками ПЛК и CoDeSys совместно.

Среда программирования – это та часть, с которой непосредственно имеет дело пользователь (рис.1). Она функционирует на ПК и является основным компонентом комплекса. Она включает редакторы для девяти языков программирования ПЛК, в том числе стандартные языки МЭК 61131-3. Пользователь может выбрать один из них и программировать простыми средствами либо задействовать всю мощь новейших инструментов CoDeSys. На выходе CoDeSys непосредственно дает быстрый машинный код. Поддержаны все распространенные семейства микропроцессоров от 16 до 64-разрядных.

Рис. 1. Редактирование FBD диаграммы в CoDeSys

Среда программирования CoDeSys включает набор инструментов для подготовки и отладки программ, компиляторы, конфигураторы, редакторы визуализации и т.д. При необходимости функциональность системы дополняется опциональными компонентами. Проект CoDeSys можно хранить не только на диске ПК, но и в контроллере, если он имеет достаточный объем памяти, что позволяет избежать потери исходных текстов или путаницы в проектах. Для больших проектов предусмотрено использование системы контроля версий (SVN).

Для отладки пользователю не нужно открывать специальных отладочных окон или составлять каких-либо списков переменных. При подключении к ПЛК редакторы ввода программ “оживают”. Непосредственно в них отображаются значения всех видимых на экране переменных. Причем в сложных выражениях видны все промежуточные результаты.

В CoDeSys V3 впервые в мире была реализована поддержка объектно-ориентированного программирования (ООП) в языках стандарта МЭК 61131-3. Разработка концепции была начата в 2005 г. [2]. Введен ряд новых ключевых слов для определения методов, свойств, интерфейсов и наследования, позволивших эволюционно развить в объект привычный функциональный блок. Пользователь может по своему усмотрению писать программы привычным образом или использовать объекты. Такой подход не создает лишних проблем “старым” прикладным программистам. В тоже время молодые специалисты, изучившие ООП в вузе и уже не представляющие себе серьезную работу без данной технологии, смогут реализовать свой потенциал. Предложенные расширения ООП прошли проверку временем в CoDeSys, получили широкое одобрение и будут включены в стандарт.

Из новшеств CoDeSys, добавленных за последний год, следует отметить странично-ориентированный FBD и поддержку языка Python для автоматизации работы в среде программирования. Обычно для таких целей используются пакетные файлы. Они удобны для примитивных задач, но не позволяют выполнять разные действия по условиям, разобрать XML файл, обработать результаты и отправить их по электронной почте. Использование Python снимает все мыслимые ограничения.
CoDeSys включает конфигураторы ввода/вывода с поддержкой полевых сетей Modbus, PROFIBUS, PROFINET, DeviceNet, CANopen, J1939, EtherCAT, SERCOS III, Ethernet IP и большое число сервисных модулей.

CoDeSys поставляется бесплатно. С сайта 3S-Smart Software Solutions доступен для загрузки полнофункциональный дистрибутив. В него входит интерфейс и интерактивная документация на русском языке.

CoDeSys Automation Platform

В CoDeSys V3 впервые в мире реализована сквозная платформа автоматизации. Не только система исполнения собирается из компонентов с фиксированными интерфейсами, но и среда программирования. Она основана на технологии Microsoft .NET. Automation Platform позволяет разобрать CoDeSys на отдельные компоненты и собрать требуемым образом, добавив собственные компоненты. Это позволяет изготовителям ПЛК прозрачно интегрировать собственные программные инструменты и технологию CoDeSys.

Типовые области применения CoDeSys Automation Platform:

расширение функциональности CoDeSys: возможность добавления в среду программирования нового редактора программ, инструмента конфигурирования специализированной полевой сети, автоматизация некоторых типовых операций (мастера) и др.;

замена составных компонентов (plug-in) CoDeSys: если штатный компонент среды программирования не удовлетворяет требованиям пользователей, то возможно заменить его, например, изменить форму отображения программ, вид окон и др.;

создание собственного программного комплекса на базе CoDeSys. Известными примерами могут служить системы SoMachine от Schneider Electric и TwinCAT 3 от Beckhoff.

Система исполнения CoDeSys Control

CoDeSys Control – это часть, которая должна быть встроена ПЛК. Нередко возникает вопрос: “Если CoDeSys даёт на выходе машинный код, то зачем вообще нужна система исполнения?” Ответ кроется в стержневой идее технологии ПЛК. Программируя ПЛК, пользователь должен думать исключительно о сути прикладной задачи. Его не должны волновать организация памяти, процедуры опроса модулей ввода/вывода, способы синхронизации данных, функции сетевого обмена и связи с верхним уровнем, вызовы циклических и событийных задач, организация фиксации выходов при отладке на оборудовании и т. п. Так, для получения значения входа в своей программе, прикладной программист ПЛК выбирает переменную и задает в диалоговом окне единицы измерения, параметры фильтрации и другие параметры. Всю черновую работу за него должна выполнить система исполнения. Если программисту приходится думать о передаче байтов или вызове библиотечных функций для работы с вводом/выводом, то это не ПЛК? и говорить об удобстве и надежности прикладного программирования не приходится.

В общей сложности CoDeSys Control включает более 200 компонентов. Каждая “сборка” под конкретную модель ПЛК будет отличаться. Ее состав определяется возможностями аппаратуры и типом ПЛК. Включение абсолютно всех компонентов, на всякий случай, привело бы к неоправданному росту аппаратных ресурсов и стоимости. Например, включение функции “горячей” правки кода без остановки ПЛК удваивает требования к ОЗУ. Некоторые компоненты представлены в нескольких вариантах. Например, компонент “менеджер задач”. Самый дешевый ПЛК может иметь единственный аппаратный таймер, “тикающий” каждые 10 мс, и не иметь ОС. Для него подойдет простой планировщик циклических задач без вытеснения. С ним не смогут работать некоторые другие компоненты, например, ЧПУ или стек CANopen, но они и не требуются в ПЛК такого уровня. Для ПЛК с мощным 32- или 64-битным процессором и ОС РВ разумно включить наиболее совершенный “менеджер задач” с поддержкой событий, реального времени и нескольких приложений в одном устройстве. С каждым таким приложением можно работать как с независимым ПЛК: загружать, запускать, останавливать и отлаживать программы, не влияя на работу других приложений.

CoDeSys Control может функционировать под управлением любой ОС или даже без нее. Наиболее часто используют ОС VxWorks, Windows CE и Linux. Имеются адаптации под RT-OS32 (RTKernel), QNX, Nucleus, pSOS, OS9, TenAsys INtime. Изготовитель оборудования может самостоятельно адаптировать CoDeSys Control под другую ОС.

В некоторых случаях адаптация CoDeSys Control в свое оборудование может быть проблематична. Ограничением может стать отсутствие технических специалистов, соответствующего уровня или экономические условия. В таких случаях целесообразно использовать готовые процессорные модули (PLCcore) с уже адаптированным и установленным CoDeSys Control. Популярным PLCcore для CoDeSys является Beck IPC@CHIP.

CoDeSys Control непрерывно развивается. Добавляются принципиально новые компоненты, совершенствуются и “мелкие детали”. Например, для современных быстрых ПЛК c CoDeSys пришлось вводить новый тип данных для работы с наносекундными интервалами времени. Обычному пользователю CoDeSys не нужно заботиться об устройстве системы исполнения. Ему достаточно только периодически загружать и устанавливать бесплатные обновления в соответствии с рекомендациями изготовителя ПЛК.

SoftPLC CoDeSys SP RTE

CoDeSys SP RTE представляет собой специальную систему исполнения для ОС семейства Windows со встроенным ядром жесткого реального времени. Она позволяет превратить обычный компьютер в быстродействующий ПЛК. Ввод/вывод подключается через полевые сети. SP RTE обеспечивает стабильность рабочего цикла МЭК программ в диапазоне микросекунд и работу контроллера при зависании ОС.

CoDeSys визуализация

Среда CoDeSys оснащена встроенной системой визуализации и операторского управления. Непосредственно в CoDeSys можно построить графический интерфейс оператора или модели объекта, без использования внешних инструментов. Для интеграции с программой достаточно прописать в свойствах элементов соответствующие переменные. Не требуется создавать символьные файлы, настраивать связь или выполнять иные рутинные операции. Если работает CoDeSys, то работают и средства визуализации.

CoDeSys HMI часто называют SCADA-системой. Это не верно. Она не имеет столь мощных графических средств, не использует OPC, не имеет средств ведения суточных архивов и интеграции с БД, а также функций программирования. Но она обеспечивает управление в реальном времени и на порядок менее требователена к ресурсам. Весь интеллект системы сосредоточен в ПЛК, а HMI выполняет роль тонкого клиента отображения. Ее типичные применения – это встроенные пульты управления станками, погрузчиками, кранами, трамваями и подобными системами, где нужна быстрая гарантированная реакция и стоимость оборудования критична.
Сервер данных (Data Server) позволяет собирать данные от нескольких контроллеров. При этом не обязательно, чтобы все они программировались в CoDeSys. Сервер данных является частью системы исполнения.

Визуализация CoDeSys может параллельно работать на нескольких устройствах:

CoDeSys WebVisu позволяет контролировать работу своей системы из любого места и в любое время через Internet. Web-сервер является компонентом системы исполнения.

CoDeSys HMI – это отдельная утилита, предназначенная для операторского управления с отдельного компьютера локальной сети.

CoDeSys TargetVisu – интегрированный компонент системы исполнения, предназначенный для создания панельных ПЛК. Применяется в локальных пультах управления.

Из последних новшеств визуализации CoDeSys выделяется пакет библиотек элементов визуализации для различных прикладных областей с современным графическим представлением [См. рис 2.]. Наиболее впечатляющим элементом можно назвать 3D редактор движений для SoftMotion.

Рис.2. Визуализация панели автомобиля

CoDeSys SoftMotion

CoDeSys SoftMotion – это встроенный в среду программирования и систему исполнения CoDeSys функциональный набор средств управления движением: от простых перемещений по одной оси до многоосевых ЧПУ. Поддерживается движение по лекалам (ECAM) и интерпретация программ в G-кодах (Рис.3). В среду программирования встроен текстовый и графический 3D редактор для задания траекторий и набор элементов визуализации стандартных узлов мехатроники. Установить SoftMotion можно на 32-битный ПЛК с математическим сопроцессором.

Рис. 3. G-код движения в CoDeSys и его визуальное представление

CoDeSys V3 Safety

Комплекс Safety ориентирован на обеспечение безопасности там, где присутствует человек. CoDeSys Safety представляет собой комплекс инструментов, который позволяет разрабатывать контроллеры, удовлетворяющие требованиям стандарта IEC 61508 для оборудования систем безопасности Safety Integrity Levels 3 (SIL3). Он включает безопасную систему исполнения, безопасный компилятор, конфигураторы безопасных сетей, библиотеки PLCopen Safety и набор документов, включающий методику тестирования и сертификации. Эта технология существенно сложнее обычных ПЛК систем. Так, например, до запуска кода выполняется целый ряд специальных проверок. После загрузки машинного кода в контроллер и создания загрузочного образа код скачивается обратно в среду разработки, производится его декомпиляция и сравнение с исходным текстом. Безопасные контроллеры уровня SIL3 должны проходить обязательную сертификацию. Это весьма сложный и дорогостоящий процесс. Применение CoDeSys Safety позволяет существенно упростить его.

Выше упоминалась технология PLCcore, позволяющая радикально упростить создание контроллеров с CoDeSys. Похожая идея воплощена и для безопасных контроллеров. Ее основой служит сертифицированный модуль TwinSafe EL6900 компании Beckhoff. Встроив это в устройство, имеющее поддержку CoDeSys и EtherCAT Master, получаем собственный SIL3 контроллер.

Для систем уровня SIL2 все гораздо проще. CoDeSys сертифицирована как надежная система, имеющая боле 1 млн. применений. Для SIL2 используются все стандартные редакторы МЭК языков, компактная система исполнения с определенным набором компонентов, сертифицированные библиотеки элементов и безопасный ввод/вывод.

CoDeSys redundancy

В противоположность безопасным (Safety), надежные системы (Redundancy) чаще необходимы в местах, куда человеку трудно добраться, либо там, где остановка работы оборудования недопустима по технологическим или финансовым критериям. Например, 5 мин простоя линии разгрузки крупного морского порта обходятся дороже стоимости всего электронного оборудования.

CoDeSys Redundancy представляет собой специальный плагин для среды программирования и набор компонентов системы исполнения, обеспечивающий синхронизацию, диагностику и переключение основного и дублирующего контроллеров.

CoDeSys Professional Developer Edition

CoDeSys Professional Developer Edition – новый продукт комплекса CoDeSys. Он ориентирован на растущую группу пользователей, имеющих высшее образование и опыт работы с современными профессиональными системами программирования на языках высокого уровня для компьютеров. Его область – создание крупных, либо новых уникальных проектов, не имеющих аналогов. Профессиональная редакция среды разработки CoDeSys включает следующие компоненты: систему управления версиями проекта на базе Subversion (SVN), графические редакторы UML (диаграммы классов, состояний и деятельности) и статический анализатор кода. Все эти компоненты устанавливаются и интегрируются в среду программирования. Система контроля версий необходима в больших проектах над которыми работает группа людей. При сохранении изменений в обычном файле проекта CoDeSys, они записываются поверх старой информации. Она теряется бесследно. При использовании SVN сохраняется вся история исправлений с указанием кто исправлял, когда и с какой целью. Если правка вызвала сбои, то всегда есть возможность вернуться к проверенной версии на любую дату. Кроме того, один проект могут открыть несколько людей со своих рабочих мест. Каждый человек может править параллельно ‘свои’ части. Контроль версий естественным образом интегрируется в среду программирования. Так, для всех языков программирования, включая графические предусмотрены визуальные средства сравнения версий.

Интеграция UML стала следующим логическим шагом после реализации в CoDeSys ООП. Диаграмма классов дает визуальное представление зависимостей функциональных блоков, методов и интерфейсов, которые теперь могут редактироваться графически. Диаграммы состояний и диаграммы активности представляют собой новые языки для разработки прикладных проектов. Они позволяют описывать состояния и переходы сложных процессов. Оба высокоуровневых языка призваны упростить совместную работу программистов и инженеров технологов, ускорить построение структуры приложения и собственно программирование.

Статический анализатор кода осуществляет проверку исходного кода МЭК программ на соблюдение более чем 50 адаптивных правил. Он выявляет потенциально опасные места, способные вызвать ошибки и устранить их сразу, еще до фазы отладки и тестирования проекта. Это улучшает качество кода, ускоряет работу и позволяет избежать ошибок с самого начала работы.

Комплект инструментов профессионального разработчика продолжает расширяться. В настоящее время в разработке находятся: профилировщик кода и генератор тестов.

CoDeSys Application Composer

CoDeSys Application Composer напротив, ориентирован не на сложные научные проекты, а на повседневные прикладные задачи. В них решающими являются время создания проекта, простота процесса программирования и надежность итогового кода. При выполнении работ по автоматизации однотипных объектов, например умных домов или типографских машин, Application Composer позволит повысить производительность труда на два порядка.

Составление прикладного проекта выполняется на основе заранее подготовленных наборов прикладных программных модулей. Такой модуль может обслуживать определенную часть машины или системы. Например, это может быть пневматический цилиндр, автооператор, терморегулятор, либо программный блок управления доступом или конфигуратор сети. Каждый модуль включает программный код, конфигурацию входов/выходов, параметры и графическое представление для визуализации. Пользователь строит структуру своей системы управления, используя необходимые модули. Он определяет их настройки и связи в специальных редакторах. Затем интегрированные генераторы кода автоматически создают законченное, хорошо структурированное программное приложение на языках стандарта МЭК61131-3. Одновременно генерируется соответствующая визуализация. Программы компилируются и загружаются в контроллер. Пользователь может просматривать и корректировать полученный код при необходимости.

Рис. 4. Проект управления перекладчиком в Application Composer

Такой подход позволяет перейти от рутинного программирования к модульному проектированию прикладных проектов. Он открывает двери пользователям, хорошо знающим устройство машин, технологию соответствующего производства, но не владеющих программированием.

Заключение

Благодаря своим отличным функциональным возможностям, надежности и открытым интерфейсам, CoDeSys стал лидером в области инструментов программирования ПЛК. Не случайно он выбран в качестве базового инструмента многими ведущими мировыми поставщиками аппаратных решений для промышленной автоматизации.

Разработчик CoDeSys – компания 3S-Smart Software Solutions GmbH (Германия) никогда не ставила приоритетной задачи “бюджетного внедрения” и распространения CoDeSys путем удешевленной либо упрощенной установки на любые типы контроллеров любых компаний. Для запуска CoDeSys Control достаточно 1 дня, но выпуск нового ПЛК с CoDeSys – это всегда серьезная работа, требующая грамотной организации, наличия квалифицированных специалистов и строгого выполнения ряда этапов, от сборки до выходного тестирования изделия в целом.

В мае 2012 г. в г. Смоленске проходила ежегодная конференция пользователей CoDeSys, на которой главный инженер Европейского отделения компании Hitachi господин Kenji Shimoda рассказал о переводе новых контролеров Hitachi с фирменного ПО на CoDeSys, занявшего немногим более 1 года. Это небольшой срок для разработки нового ПЛК с CoDeSys. Перевод включал собственно адаптацию, интеграцию с собственным ПО, тесты всего функционала на опытных ПЛК, написание руководства по применению и стартовых примеров, обучение дистрибьюторов. Типичный для некоторых конкурирующих МЭК систем подход ускоренной бюджетной установки с переносом части затрат и технических сложностей на плечи пользователей в CoDeSys принципиально не применим. Вы не встретите CoDeSys в ПЛК, собранных “на коленке”. Это всегда будут продукты компаний, твердо стоящих на ногах и имеющих достаточно ресурсов на грамотный маркетинг, качественную разработку и сопровождение.

Простота и удобство именно для конечного пользователя – это стержневая идея CoDeSys. Компания 3S-Smart Software Solutions с немецкой целеустремленностью придерживается ее многие годы. Состав компонентов CoDeSys измеряется уже сотнями и продолжает расти. Но, каждый новый компонент нацелен на упрощение решения нового круга прикладных задач. Своим непрерывным развитием и огромной популярностью CoDeSys обязан исключительно конечным пользователям.

Литература

1. Jorn Linke. Der SPS-Benchmark: Das Ergebnis. Computer Automation. 2011. 9.

2. Дитер Хесс. Объектно-ориентированные расширения МЭК 61131-3 // Современные технологии автоматизации. 2006. №2.

Петров Игорь Викторович – директор ООО “ПК Пролог”.

Контактный телефон (481-2) 38-29-31.

www.prolog-plc.ru

Кто такой Software Engineer. Программная инженерия VS “просто” программирование

Предлагаем вашему вниманию адаптацию статьи Самира Буна (Samer Buna) о различиях между программной инженерией и программированием, или чем разработка концепции программного обеспечения отличается от «просто кодинга». Все программные инженеры могут кодить, но не все программисты способны разрабатывать концепции программного обеспечения. Некоторые люди не любят определение «Программный инженер» (он же инженер-программист, он же Software Engineer) из-за того, что чаще всего слово «инженер» мы используем, говоря о чём-то более физическом — строительстве, например. Наша статья, разумеется, не о самом термине. Если он вдруг вызывает у вас отторжение, его легко можно заменить на что-то связанное с креативностью. «Создатель ПО», «автор ПО» … да хоть «Творец ПО»!
Когда мы говорим о «программном инженере», мы подразумеваем человека, чьей основной задачей является не просто написание кода, но создание качественного приложения. И в этом он видит своё призвание, применяя в работе научный подход и статистические методы. Для него программирование — не просто способ заработка для прокорма.
Умение программировать автоматически не делает из человека программного инженера. Научиться кодить может любой, и это куда проще, чем кажется. Каждый может создать простую программу для собственного использования, но это не дает гарантий, что эта же программа подойдёт другим. Мой любимый пример такой: многие из нас поют в дУше, но, увы, далеко не всегда это исполнение достойно профессиональной сцены. Разумеется, за высокими музыкальными впечатлениями вы, скорее всего, обратитесь к профи. Вам нужны еще примеры?
  • Все мы учим математику и письмо в школе, но это не делает нас математиками и писателями.
  • Большинство из нас способны приготовить сносное, а порой — и очень вкусное блюдо, но не каждый рискнёт приготовить стол на 100 персон для званого ужина в посольстве. В этом случае мы нанимаем повара.
  • Готовы ли вы прямо сейчас всецело доверить постройку нового дома соседскому ребёнку, создающему впечатляющие шедевры из Lego?
Мой главный посыл, который я пытаюсь донести в этой статье: простые программы очень сильно отличаются от программ, спроектированных инженерами. Простейшее определение процесса программирования: составление упорядоченной последовательности действий для компьютера с целью получения чего-то конкретного на выходе, при заданных вводных параметрах. Процесс программной инженерии — это проектирование, написание, тестирование и курирование компьютерной программы с целью решить задачи многих пользователей. Речь идет о создании надежных и безопасных решений, которые выдержат проверку временем и будут работать для некоторых возможно заранее неизвестных задач, помимо очевидных. Программные инженеры знают все о задачах, которые они решают, решениях, которые они предлагают, ограничениях этих решений, их конфиденциальности и безопасности. По моему мнению, если человек не понимает сути проблемы, ему не стоит даже начинать программировать её решение.

Инженерный склад ума — поиск прикладных решений

Программные инженеры не считают своей главной целью написание программ как таковое. Они думают в масштабах обеспечения потребностей и решения проблем. Это важно, поскольку не каждая проблема требует создания программного решения. С некоторыми из них вполне можно разобраться с помощью уже существующих программ. Возникновение некоторых проблем иногда можно предсказать заранее, а с помощью грамотного проектирования программ – избежать в будущем.

«Интеллектуалы решают проблемы, гении предотвращают их»

– Альберт Эйнштейн

Сложные проблемы зачастую требуют написания множества программ. Существуют задачи, которым нужны параллельно работающие приложения, иные нуждаются в последовательном выполнении нескольких программ. Ряд проблем можно решить, просто обучив пользователей. Перед тем, как приступить к созданию программы, инженер ПО задает себе ряд вопросов:
  • Какие задачи я должен решить?
  • Что еще, кроме написания кода, можно сделать, чтобы решить их?
  • Что я могу сделать для упрощения решения этих задач с помощью приложения?

Качество программы и качество кода

Хорошие программы понятны и читабельны. Их легко расширять, они отлично ладят с другими программами, и работа с ними не станет вашим ночным кошмаром. Качество кода не является предметом переговоров. Оно должно быть высоким, и всё тут. При его рассмотрении недопустимы отговорки вроде плохого настроения кодера или слишком сжатых сроков исполнения (ох уж эти дедлайны!). Один из самых важных моментов разработки ПО — проектирование программы таким образом, чтобы в дальнейшем её было легко поддерживать и модифицировать (привет, ООП!). Сегодня практически всё ПО модифицируемо, зачастую этот процесс происходит даже без участия пользователя или не требует от него ничего, кроме «пришло обновление вашей программы, нажмите ОК или Отложить». Разумеется, пользователи вправе требовать от приложений новых функций (особенно если речь идёт о долгоиграющем корпоративном ПО, которое пишут на Java, или об онлайн-играх, в которые можно играть годами).
Хотите знать больше о программировании на Java? Вступайте в группу Java Developer!
Сам по себе кусок кода вряд ли можно назвать полезным. Полезные функции ПО начинаются там, где разрозненные куски приложений взаимодействуют между собой, обмениваются данными и работают сообща, выполняя задание представления данных и интерфейсов пользователям. Программы следует проектировать с учетом этих моментов! Какие сообщения они принимают? Какие события мониторят? Как происходит аутентификация и авторизация? Другой не менее важный признак хорошей программы — понятность кода, а не количество пройденных приложением тестов или даже не хорошее покрытие тестами. Казалось бы, простые вопросы: «Может ли кто-то, кроме меня, разобраться с моим кодом?», «Смогу ли я, написав сегодня этот код, понять его через несколько недель?». Популярная цитата о двух самых сложных вещах в программировании гласит:

«Есть только две действительно сложные вещи: инвалидация кэша и именование сущностей»

— Фил Карлтон.

Читаемость кода куда важнее, чем принято считать. К сожалению, невозможно определить точные показатели или параметры для ясности кода. Отчасти помогут запоминания общепринятых языковых норм, хороших моделей ПО и методов разработки. Но обычно этого недостаточно. У настоящих профессионалов со временем и опытом развивается, если можно так сказать, «чувство ясности», нечто сродни интуиции. Здесь хорошо подойдет метафора с письмом: знание большого количества слов, не поможет вам написать краткий и ясный по смыслу.

«Я написал бы короче, но у меня не было времени»

— Марк Твен.

Возможность легко и быстро исправлять баги — ключевой признак хорошего программного обеспечения. Ошибки в программе должны отправлять четкие сообщения и централизовано регистрироваться для отслеживания. Когда приходит сообщение о новой ошибке, тот, кто будет ее устранять, должен иметь возможность для отладки. Ему нужно легко подключаться к системе, получать доступ к информации о выполнение в любое время, а также иметь возможность легкой проверки работоспособности любой части системы.

Окружения и тестирование

Когда инженеры-программисты разрабатывают приложения, они делают всё от себя зависимое, чтобы те работали на компьютерах разной архитектуры и с разными ОС. Важно, чтобы ПО работало при разных разрешениях и ориентациях экрана, а ещё — чтобы оно не «ело» больше памяти и процессорных мощностей, чем требуется. Если речь идёт о веб-приложениях, то они должны работать во всех основных браузерах. Создавая декстопное приложение, нужно удостовериться, что оно запускается и корректно работает и на Mac, и на Windows, и на Linux. Ну а программа, зависит от данных, то приложение должно работать даже в случае медленного соединения с данными либо его отсутствия. Чтобы написать часть программы, инженеры продумывают всевозможные варианты сценария, а также планируют их тестирование. Все начинается с выбора идеального варианта, при котором все работает без ошибок. Затем они документируют всевозможные вероятные проблемы и заносят их в план тестирования. Некоторые инженеры начинают с написания кода, который они называют тестовым примером и в котором имитируются сценарии всех вероятных проблем и ошибок. А затем уже пишется программа, которая сможет работать при любом из рассмотренных вариантов. Уникальной способностью талантливого инженера ПО является не знание, как написать код, а понимание того, что именно приложение должно делать на выходе и как этого добиться. Инженеру необходимо при неполных, а, возможно, и неоднозначных требованиях заказчика к ПО правильно их оценить и «понять».

Стоимость и эффективность

Программный инженер в большинстве случаев может быстро решить проблему. Если вы думаете, что при найме на работу «дорогого» опытного программиста вы увеличите затраты, подумайте еще раз. Чем более опытным окажется нанятый программист, тем быстрее он сможет предоставить простое, аккуратное, надежное и легкое в эксплуатации решение. В долгосрочной перспективе это однозначно уменьшит затраты на разработку ПО. Также необходимо учитывать затраты на исполнение программы. Любая программа использует вычислительные ресурсы, а они — не бесплатны.
Задача Software Engineer состоит в написании эффективного кода, который не использует вычислительные ресурсы без необходимости.
Например, кеширование часто используемых данных — одна из возможных стратегий, применяемых для получения желаемого результата. Но это — только один из, наверное, сотен инструментов и решений, которые могут сделать программу быстрее и эффективнее. Начинающий программист может предоставить вам дешевое решение, но использование такого решения, в конечном итоге, будет стоить вам и вашим клиентам намного дороже, чем в случаи если бы вы работали с опытным разработчиком, создавшим, в первую очередь, эффективное решение.
Ориентация на удобство пользователя
Хороший программист ведет разработку с мыслью об Опыте Пользователя (User Experience (UX)). Взаимодействие «человек-машина» — тема с бесконечным количеством исследований и решений. Чем больше решений применяется, тем лучше должна получится программа. Вот несколько примеров, просто для того что бы вы прочувствовали, что это за направление такое:
  • Когда ведется разработка форм для ввода данных, таких, как e-mail, хорошая программа должна игнорировать регистр букв для адреса электронной почты. Она не должна выдавать ошибку, если нажата клавиша CAPSLOCK, поскольку адрес электронной почты уникален в нижнем регистре. Если программа принимает на ввод новый адрес электронной почты, проверяйте его на ранних этапах ввода, чтобы предупредить пользователя о том, что он использует неверный формат адреса. Такое решение включает как очевидные проверки вроде пропущенный знак «@», а также не столь очевидные, как, например, проверка на неправильный порядок символов вроде «gmail.ocm»

  • Когда пользователь перенаправляется для выполнения какого-нибудь действия, хорошая программа должна запомнить его текущее положение и вернуть его обратно после того, как он закончит. Хорошая программа также должна запомнить уже переданные пользователем данные, важные для дальнейшего с ним взаимодействия.

    Допустим, вы ищете авиаперелеты как Гость на Expedia. Позже вы решаете создать учетную запись. Приложение должно сохранить все ваши предыдущие поисковые запросы в новой учетной записи, и вы должны иметь к ним доступ с других устройств.


  • Хорошая программа разрабатывается с мыслью о сценариях поведения пользователя. Не нужно просто добавлять новые возможности по принципу «чтобы было», поставьте себя на место пользователя. Однажды я бронировал билеты на самолет и забыл указать мой номер часто летающего пассажира. После получения подтверждения я решил пойти на сайт авиакомпании и добавить его, чтобы получить скидку. Чтобы понять, как это сделать, я возился на сайте с добрых 10 минут. Приложение было настолько неочевидным, что я попросту бесцельно лазил по разным страничкам сайта, дабы найти то, что мне нужно. Позднее я обнаружил, что уже пару раз попадал на нужную страничку, но даже не понял этого, так как нужное мне поле затерялось среди других подобных полей огромной формы.

    Оказалось, что для того, чтобы отредактировать информацию о поездке, мне нужно было прокрутить около двадцати строк формы, ввести номер карты лояльности и номер телефона, без которого форму нельзя отправить на проверку. Это пример программы, которая разрабатывалась без мысли о том, насколько пользователю будет с ней удобно.

Надежность, защищенность и безопасность

По моему мнению, самое важное отличие профессионального разработчика программного обеспечения от любителя — учет таких параметров, как надежность, защищенность и безопасность приложения при его создании.
Настоящий профессионал знает, что он несёт ответственность за безопасность и защищенность своего решения.
Части программы должны быть устойчивы к некорректному вводу, некорректным состояниям и неправильному взаимодействию. Это действительно очень трудно обеспечить и это основная причина, по которой мы слышим истории о том, что люди гибнут из-за ошибок в программном обеспечении. Пользователи вводили, вводят и будут вводить некорректные данные в программу. Это нужно принять, как факт. Причём некоторые будут делать это специально, с целью сломать приложение и добраться до ресурсов, доступных ему. Вот пример из реальной жизни: особа, якобы ответственная за недавнюю утечку данных Equifax, обвиняется в невыполнении своих служебных обязанностей, которые заключались в разработке решений, устойчивых к плохому и злонамеренному вводу во всех программных продуктах, поступающих в общий доступ. Случаи, имеющие отношение к информационной безопасности, связаны не только с неправильным и вредоносным вводом, но также и с правильно вводимыми данными. Если пользователь забыл свой пароль, сколько раз он может пробовать его ввести? Заблокируете ли вы его после этого? А что, если кто-нибудь другой пытается заблокировать его учетную запись? Может ли пользователь передавать свои учетные данные по незашифрованному каналу передачи данных? Что, если запрос на вход поступил из необычного места? Что вы будете делать, если попытка входа похожа на автоматическую? Что вы сделали для того что бы защитить ваших пользователей от межсайтового скриптинга и межсайтовой подделки запросов и банального фишинга? Есть ли у вас резервная стратегия на случай DDoS-атаки ваших серверов? Эти вопросы указывают только на некоторые проблемы, которые необходимо учитывать. Защищенная программа не сохраняет важную информацию в текстовом виде. Она защищает её с помощью сложного одностороннего шифра (такого, с помощью которого легко зашифровать, но практически невозможно расшифровать без ключа). Это резервные меры на случай, если программу всё-таки взломают. Хакеры обнаружат зашифрованные данные, которые бесполезны для них. Неожиданные проблемы возникают даже в лучших программах. Программиста, который не готов к их возникновению, вряд ли можно назвать профессионалом. Пока он не ожидает неожиданного поведения, он не инженер. Он — «автор небезопасных программ». Ошибки в программах не всегда очевидны. Наши интеллектуальные возможности предвидеть и предотвращать известные ошибки ограничены. Вот почему программные инженеры понимают значимость хороших инструментов, позволяющих им писать правильное и безопасное программное обеспечение.

Необходимые инструменты

Нет сомнений, нам нужны разные и хорошие инструменты разработки. Их роль часто недооценивают, но на самом деле они изрядно экономят время и силы, упрощая некоторые задачи на порядок. Представьте, если бы вам до сих приходилось заливать файлы по FTP для развертывания, так сказать, по старинке. Вообразите отладку проблем сети и производительности без Chrome DevTools! А как неэффективно в наши дни было бы писать код на JavaScript без ESlit и Prettier! Любой инструмент, сокращающий время обратной связи, когда вы пишите код, должен быть принят с радостью. Когда я нахожу незнакомый мне ранее, но действительно полезный и действенный инструмент, я могу сожалеть лишь о том, что я не использовал до этого счастливого момента.
Более качественные и современные инструменты помогут вам стать лучшим программистом. Находите их, используйте, цените, и, если можете, — улучшайте их. И не зацикливайтесь на одном и том же: кто знает, возможно, с новым инструментом вы один раз потратите время на установку и изучение, а затем будете решать задачи в разы быстрее?

Эволюция программной инженерии

Никто не может изучить программную инженерию за два месяца, за полгода, и даже за год. Вас не научат быть программным инженером на курсах, в университете или в учебном лагере. Я учусь последние двадцать с лишним лет и продолжаю учится сейчас. Я смог спокойно называть себя опытным программистом только после десятилетия обучения и разработки, создания и поддержки приложений, которыми пользуются тысячи пользователей. Программная инженерия — не для всех, но каждый должен учится решать свои задачи с помощью компьютера. Если вы можете научиться писать простые программы, вам стоит это сделать. Если вы можете научиться использовать общедоступное программное обеспечение, вам стоит это сделать. Если вы можете научиться использовать программы с открытым исходным кодом и дорабатывать их для себя, вы получите суперсилу! Каждый день приносит разработчикам новые задачи, новые проблемы, поэтому и нужна программная инженерия. Главная задача этой профессии — создавать ПО так, чтобы обычному человеку не пришлось разбираться с ним по многу лет. Чтобы для взаимодействия с программами не было нужды в долгой учёбе. И ещё —программные инженеры всё время думают над созданием более совершенных инструментов, способных решать более сложные известные проблемы, и делать все возможное, чтобы новые проблемы появлялись как можно реже.

Разрыв между пользователем и программистом

Часто проводится четкое различие между «использованием компьютера» и «программированием». Использование компьютера может включать в себя простое действие, например открытие веб-браузера и чтение новостей. Программирование может включать что-то вроде создания самого веб-браузера.

Это похоже на два разных мира. Очевидно, что существует значительная разница в доступности и кривой обучения. Однако мне интересно, связано ли это различие только с масштабом и величиной или существует более глубокое разделение между использованием компьютера и программированием компьютера.

Иногда мы видим функции в основных приложениях, которые ставят обычного пользователя в роль, более близкую к роли программиста.

  • Макросы в текстовых процессорах, например, являются (иногда) простым языком программирования. Табличную программу, такую ​​как Microsoft Excel, можно рассматривать как единую платформу для разработки (у меня есть теория, что если бы мы каким-то образом изобрели Excel 50 лет назад, мы бы жили на Марсе и получили бы лекарство от рака).
  • Правила в почтовой программе.Outlook или другие почтовые программы позволяют пользователям устанавливать простые условные выражения для файлов или выполнять другие действия с электронной почтой. Этот относительно простой набор правил оказывается весьма действенным.

Интересно, не зашли ли мы слишком далеко в этом различии. Я не предлагаю родителям изучать C ++. Они вполне довольны электронной почтой, просмотром веб-страниц и обработкой текста. Тем не менее, я беспокоюсь о непредвиденных последствиях, которые могут возникнуть из-за идеи, которую мы выжигали в своем сознании, что программисты – это программисты, пользователи – это пользователи, и что они никогда не встретятся.

Строим ли мы наши системы таким образом, чтобы сократить разрыв между пользователями и программистами? Создаем ли мы системы с предвзятостью, из-за которой пользователям становится сложно или невозможно создавать свои собственные функции?

Я не ожидаю, что все Joe Hotmail начнут писать драйверы устройств. Однако есть технологии, которые были смещены в другую сторону: где пользователь часто является создателем. HTML, например, был достаточно простым языком, который, даже если он не добрался до среднего конечного пользователя, действительно позволял гораздо большему кругу, чем «программисты», делать интересные и творческие вещи.

Пакетные файлы

DOS были достаточно просты, чтобы многие пользователи, которые не считали себя «программистами», могли делать всевозможные мощные вещи (хотя, возможно, это было из-за жестокой необходимости). Я помню, как один старый школьный друг написал простой командный файл, который запускался с дискеты в нашей школьной сети. Он отображал приглашение, которое выглядело точно так же, как реальный экран входа в сеть. Когда ничего не подозревающий пользователь вводил свое имя пользователя и пароль, он выводил реалистично выглядящее сообщение об ошибке и записывал имя пользователя / пароль на диск (атака «дискета посередине»?).Сбитый с толку пользователь переходил на другую машину, а мой друг собирал свой диск, полный сетевых паролей в конце дня. Ключевым моментом является то, что это было возможно при очень небольшом понимании «программирования».

Вот несколько задач, которые кто-то может захотеть выполнить:

  • Сообщите мне, когда обменный курс канадской / американской валюты упадет ниже определенного значения. Как бы вы это сделали? Excel может получать данные об обменном курсе из различных веб-источников.Теперь нам нужен способ регулярно проверять это и передавать информацию в какое-либо уведомление (IM или электронная почта).
  • Возьмите все электронные письма, которые я получаю от моего коллеги по старой школе с вложениями WordPerfect 5.1, и конвертируйте их в документы в формате Rich Text Format. Как бы вы это сделали? Получите все вложения WordPerfect от этого конкретного отправителя, откройте их и сохраните как файлы RTF с тем же именем в целевом каталоге.
  • Распечатайте 5 лучших статей на первой полосе New York Times в 6 утра.

Это несколько примеров относительно простых задач, которые было бы сложно или невозможно настроить для большинства людей. Можно ли передать такую ​​власть в руки начинающих пользователей компьютеров? Все отдельные компоненты этих примеров задач относительно просты с общими приложениями. Слишком сложно связать их клеем.

Это случай профессионалов, сговорившихся с целью не дать простому народу попирать их священное царство, или это просто трудно сделать хорошо?

В связи с этим, Алан Кей выступил с докладом на недавней конференции Emerging Tech, на которой было показано видео, на котором дети «программируют» простое физическое поведение для целей обучения (доступно видео презентации в формате QuickTime).

ОБНОВЛЕНИЕ

: Вскоре после того, как я сделал этот пост, я наткнулся на пост Мэтта Джонса по этой теме.

В чем разница между кодированием и программированием?

Мне потребовалось много времени, чтобы понять, что на самом деле означают термины «программирование , » и «кодирование », и что влечет за собой каждое поле. И я уверен, что я не единственный, кого смущали эти два термина, когда я был новичком в технологиях.

Некоторое время я думал, что это одно и то же, и мне потребовалось некоторое время, чтобы понять, что есть различия между двумя «мирами».

В этой статье я объясню основные различия между кодированием и программированием, а также то, как они работают совместно для разработки приложений и сайтов.

Итак, давайте исследуем эти термины и то, как профессионалы используют их, сначала поняв, что они означают.

Что такое кодирование?

Кодирование – это, по сути, перевод кода с человеческого языка на машинный.

Чтобы стать кодером, вам необходимо уметь писать код на разных языках программирования, таких как Python, Java, C и так далее.Обладая этими знаниями, вы сможете предоставлять компьютеру инструкции и информацию, чтобы он выполнял программы, созданные вами или вашей командой.

Кодирование включает написание кода для создания программного обеспечения. Любое приложение, веб-сайт или игра – это программа.

Что такое программирование?


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

Чтобы создать приложение, вам необходимо выполнить несколько шагов, в том числе:

  • планирование заявки
  • проектируем
  • тестирование его функций
  • развертывание
  • обслуживание после завершения

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

Давайте попробуем объяснить это попроще, чтобы мы могли лучше понять.

Например, вы можете запрограммировать часы, чтобы они просыпались в 8 утра. Кроме того, вы можете запрограммировать включение кондиционера при выбранной вами температуре. У этих устройств есть код на бэкэнде, который работает на основе набора инструкций, предоставленных пользователем.

Различия между кодированием и программированием

  1. Основное отличие
    Кодирование – это часть программирования, которая имеет дело с написанием кода, который может переводить машина. Программирование – это процесс создания программы, которая следует определенным стандартам и выполняет определенную задачу.
  2. Инструменты
    Для кодирования не требуется столько программных инструментов, поскольку это всего лишь акт перевода кода в машиночитаемую форму. Достаточно простого текстового редактора, такого как блокнот или блокнот. Как кодировщик, вы должны знать детали синтаксиса вашего языка программирования.
    Программирование требует, чтобы вы выполняли просмотр и анализ документов, а также кодирование, требующее дополнительных инструментов. Эти инструменты включают инструменты анализа кода, генераторы кода, базы данных, среды тестирования, компиляторы, конструкторы графического интерфейса пользователя, ассемблеры, отладчики и алгоритмы моделирования.Программисту нужно много опыта, чтобы получить эти навыки. Они также должны уметь понимать и создавать сложные структуры данных.
  3. Экспертиза
    Кодировщики должны иметь базовые знания языков программирования, их синтаксиса и ключевых слов.
    Программисты должны иметь опыт создания алгоритмов, моделирования проблем, обработки данных и управления проектами – это лишь некоторые из необходимых практических навыков. Программисты также применяют свое воображение и аналитические способности, чтобы помочь им решить конкретные проблемы.
  4. Результат
    При кодировании ожидаемым результатом будет простое решение или небольшая часть проекта. Код действует как набор инструкций, передаваемых компьютеру.
    С другой стороны, программирование дает готовое к использованию приложение, программные продукты или веб-сайт.

Как кодирование и программирование работают вместе

К настоящему времени вы, вероятно, уже понимаете разницу между этими двумя терминами. Теперь, как кодирование и программирование работают вместе для выполнения различных задач?

Почему бы нам не объяснить это на примере, чтобы лучше понять.Представьте, что мы создаем приложение для отслеживания чего-то вроде нашей повседневной жизни. Как эти две области будут работать вместе?

Сначала программист должен:

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

После того, как программист выполнит эти первые шаги, он передает их кодировщику.

Теперь придет кодировщик и преобразует эти идеи в код, понятный компьютеру.После завершения этого волшебного процесса законченный код передается программисту.

Теперь программист просматривает код, отлаживает его, проверяет на наличие ошибок и выполняет тесты перед публикацией конечного продукта.
Теперь вы можете увидеть, как эти два поля объединились, чтобы работать над идеей и произвести что-то, что можно будет использовать для публики.

Заключение

Если вас интересует логика, вы можете попробовать сосредоточиться на программировании, а если вы лучше запоминаете и понимаете вещи, вы можете сосредоточиться на кодировании.

Все зависит от того, какую область вы хотите исследовать, поскольку информатика – это обширная область, и она все еще развивается, не останавливаясь в ближайшее время. Так что наслаждайтесь путешествием, когда вы найдете свой путь.

Мне потребовалось время, чтобы понять, кто я – Сколько времени это займет у вас? Сообщите мне, если вы выяснили свой путь.

Если вы дочитали до этого места, я очень ценю. Вы помогаете мне развивать мое сообщество:

Свяжитесь со мной в Twitter | Insta | YouTube | LinkedIn | GitHub

Счастливое кодирование ❤

Инженер-программист против программиста: в чем разница?

Короче говоря, программисты сосредотачиваются на создании функционального кода, в то время как инженеры-программисты разрабатывают программное обеспечение с инженерной точки зрения с учетом потребностей конечных пользователей, клиентов и бизнеса.Программные инженеры сами являются программистами.


Техническая сфера относительно новая. Он новее, чем многие другие компании, и поэтому мы все еще точно понимаем, что всем следует делать. Создание команд в этой области – сложная задача, поскольку команда часто состоит из ограниченного числа членов, и каждая команда почти всегда специализируется на достижении цели или продукта.

Из-за этого существует множество свободных названий должностей для технических специалистов, и одно название может означать разные описания должностей в отрасли.Это очень похоже на то, как если бы вы сказали, что вы юрист – вы можете быть юристом по общественным интересам, юристом в сфере развлечений или даже ядовитым юристом по гражданским делам. То же самое верно для всех, кто занимается разработкой программного обеспечения.

В этой статье мы разберем два общих названия в области технологий. Мы узнаем, что значит быть программистом и инженером-программистом, в чем разница между ними и что влечет за собой каждая роль.

Программист

Найди свой матч на тренировочном лагере