електронно – DevStyleR https://devstyler.bg Новини за разработчици от технологии до лайфстайл Mon, 14 Feb 2022 12:17:44 +0000 bg-BG hourly 1 https://wordpress.org/?v=6.5.5 Ще Повлияят Ли Промените В Закона ИТ Индустрията? https://devstyler.bg/blog/2022/02/14/shte-povliyayat-li-promenite-v-zakona-it-industriyata/ Mon, 14 Feb 2022 12:14:28 +0000 https://devstyler.bg/?p=56567 ...]]> 38,2 милиона лева са предвидени за електронното управление. В бюджета е включено “най-важното нещо”, а именно електронната идентификация, коментира пред журналисти ресорният министър Божидар Божанов.

Държавна агенция “Електронно управление” (ДАЕУ) ще бъде закрита, като всички правомощия ще бъдат възложени на министъра на електронното управление. Възложено е на МС да уреди правоотношенията, които са свързани със закриването на ДАЕУ и преминаването на дирекция “Информационни технологии” от Министерство на информационните технологии и съобщенията към Министерството на електронното управление,  съобщиха от DarikNews.

Устройственият правилник на министерството е вече обнародван в Държавния вестник.

На първо четене бе одобрен и проектобюджетът за 2022 г., който предстои да бъде обсъден повторно.

]]>
За общото между софтуерната архитектура и костенурките https://devstyler.bg/blog/2021/11/05/za-obshtoto-mezhdu-softuernata-arhitektura-i-kostenurkite/ Fri, 05 Nov 2021 12:58:41 +0000 https://devstyler.bg/?p=52305 ...]]> Константин Спиров е част от компанията VMware България вече 11-та година. Там той стартира кариерата си на Senior Engineer в екипа на vRealize Orchestrator. След повишението си като Staff Engineer, се превръща един от основателите на продукта „Evo Rack”, който днес е основата на VMware Cloud Foundation. В момента Константин е софтуерен архитект във VMware Cloud on AWS.

Константин, завършили сте Националната природо-математическа гимназия, след което и ФМИ в Софийски университет. Как се породи интересът Ви към технологиите?

Аз съм типичен представител на поколението, което се запозна с компютрите в средата на 80-те години. Както много други, първо започнах с 8-битовите компютри, после преминах към 16-битовите. В гимназията се подготвях за олимпиади по Информатика и влязох в университета чрез състезателно програмиране. Това беше времето, когато още нямаше Интернет в България. Ползвахме други средства за комуникация, наречени BBS-и (бюлетин-борд системи). Това бяха малки сървърни компютри, които обслужваха потребители по телефонната линия. Аз бях последният системен оператор на първия български BBS, Микроком (разполагахме с цели две телефона, при това денонощни и  без дуплекс). В тази среда се оказах и основател на първия български e-zine (електронно списание). То се разменяше под формата на файлове между различните участници в мрежата FidoNet. От 1993-та година започнах да си изкарвам хляба с програмиране. 

Сега, като се замисля, ми е странно, че когато аз съм писал код, голяма част от днешните ми колеги все още не са били родени. Но в такива моменти се сещам за думите на Боб Мартин (Uncle Bob), че въпреки бруталната разлика при смяната на технологиите, основните принципи при разработка на софтуерните системи си остават същите. За мен е много окуражаващо да наблюдавам професионалното израстване на част от по-младите ми колеги, при което те преоткриват за себе си същите проблеми и решения, които аз самият съм налучквал преди 3 десетилетия.  

Работите като Staff Engineer във VMware и сте в компанията вече 11 години. Бихте ли ни разказали повече за Вашата позиция и за Вашия кариерен път? 

Докато бях в университета започнах работа в стартъп и останах там около 15 години. Платформата, която разработвахме, даваше възможност за бърза обработка на митнически документи. Движихме се преди Enterprise Java, и в крачка си измисляхме сами доста на брой подобни технологии. Но “”not invented here” синдрома ме притесняваше, затова въпреки успешния стартъп, взех трудното решение да напусна и да си сверя часовника с индустрията. В този момент разработената от нас система беше внедрена в повече от 50 държави по света.

Една година работих в чужбина и след това бях привлечен във VMware. Офисът на компанията беше  на 5 минути пеша от дома ми, в сграда на ул. „Г.М. Димитров“. Така преди 11 години започнах кариерата си като Senior Engineer в екипа на vRealize Orchestrator. Проектът започна от купен стартъп в Швейцария, впоследствие успяхме да пренесем цялата разработка и управление на продукта в България. Успешно „отвързахме“ ядрото от различни остарели и изоставени технологии (например MBеan, Struts, и дори целия JBoss), преминахме през сериозни одити на сигурността, вкарахме поддръжка за модерни стандарти за удостоверяване и упълномощаване. Оркестрацията често играе ролята на „тел“, усукана около различни софтуерни системи, които не си взаимодействат по достатъчно кохерентен начин. Времето, прекарано в анализ на стабилността (и нестабилността) на различните интеграции засили  интереса ми към софтуерно дефинирания център за данни и начините, по които трябва да бъде подготвян и поддържан целия софтуерен стек.

След повишението ми към Staff Engineer, станах един от основателите на продукта „Evo Rack”, който днес е основата на VMware Cloud Foundation. Първоначално се разработваше като конвергентно инфраструктурно решение. Ще обясня какво е това с една аналогия – когато си закупите нов ноутбук и го отворите за първи път, той вече е почти инсталиран,  вие допълвате само минимално количество информация като името си и мрежовите настройки. След това ноутбукът е готов. По същия начин, конвергентните решения дават възможност потребителят да си закупи цели ракове заедно със сървърите и суичовете и да му бъде предписано как точно да свърже мрежата в Leaf/Spine топология. След това с минимална първоначална конфигурация, чрез включване на ноутбук на един от сървърите на рака и бързи конфигурационни стъпки, потребителят получава целия стек на VMware – всичките взаимодействащи си продукти. Тъй като се движехме на гребена на вълната, решихме доста нови проблеми в оркестрацията. Това ми даде възможност да се сдобия и с първите си три патента. Получих и промоция в Staff Engineer II.

Днес работя в организацията за облачни решения.  От края на 2016 година софтуерно дефинирания център за данни на VMware е достъпен инфраструктурата на AWS, в днешни дни и  в почти всички големи облачни доставчици – от Google до Alibaba Cloud. Екипът в който работя, много бързо се разрасна, имаше моменти, когато почти всеки ден имах интервюта в календара си, и в момента продължаваме да наемаме нови хора.

Разкажете ни за прехода от Software Engineer към Staff Engineer – за какъв период от време се стига до тази позиция, през какви етапи на развитие се преминава?

На този въпрос има два отговора – кратък и дълъг. Краткият e – “не знам”. В повечето компании от Силициевата долина няма очакване, че програмистите трябва задължително да се стремят към позицията на Staff Engineer.

А сега е време за дългият ми отговор – когато преминах от стартъпа в голяма компания, едно от притесненията ми беше, че  западното „корпоративно мислене“ често стресира и противопоставя хората. Трудно е, ако служителите биват карани непрекъснато да се издигат по кариерната стълбица под благовидното оправание за „непрекъснато усъвършенстване”. В една пирамидална структура това е практически невъзможно. Много хора нямат големи кариерни амбиции и не желаят някой непрекъснато да ги убеждава, че тяхната кариера е едва ли не каузата на живота им. В културата на VMware този проблем е решен и то по доста естествен начин. От всеки програмист, индивидуален контрибутор, се очаква да надобрява в професията си през годините, докато не стигне Senior позиция. Но достигне ли ниво Senior MTS,(по нашенски „майстор в занаята“), може да си остане на тази позиция и до пенсия, стига това да го удовлетворява. 

За тези, които имат възможност и мотивация да продължат нататък, съществуват два варианта за развитие. Единият е мениджърската стълбица. Тя е за тези, които притежават изключително добри организационни умения. В кръга на шегата, от мениджърите ще се очаква да останат със сърце на програмист, но скрито в буркан в някое дълбоко подземие. Имам и доста колеги, които тръгнаха по този път, но бързо се отказаха, най-вече, защото не им остава време да програмират. Важно уточнение – да станеш мениджър не означава да престанеш да се занимаваш с технологии. От мениджъра се очаква не само да колаборира добре с техническия лидер и архитекта, но когато има нужда да може да ги замества в някои срещи, да намалява тежестта върху тях.  Добрият мениджър служи на екипа си, а не обратното.

Добрият мениджър служи на екипа си, а не обратното.

Другият вариант за развитие е израстване по техническата стълбица и там са staff позициите.  За хора като мен, които държат на личния си принос в проектите (както в архитектурата, така и в дълбочина), това е чудесен вариант.  Аз също имам начини да намирам хора, които да ми помагат, но при всеки проект водеща е техническата кауза, а не организационната структура. Нямам точна рецепта как се става Staff, но мога да дам насока. В една голяма организация разликата между правилното и грешното техническо решение може да струва изключително скъпо. От една страна, трябва да покажете с професионалното си поведение, че имате здрав разум – не само че мечтаете, но че може да се разчита на вас,  че спазвате обещанията си. Но другата страна, която не се подразбира, е, че е важно да изследвате областите, които не са очевидни за тези покрай вас, които нямат време да инвестират в техническата дълбочина. В тази дълбочина трябва да търсите подводни камъни и да откривате неочаквани решения. Успявате ли да правите и двете неща, мога да ви уверя че сте на една крачка от Staff.

Какъв опит имате с Java?

Така се случи в кариерата ми, че от 1996-та, та чак до днес се занимавам с проекти, основно писани на Java. Имам достатъчно задълбочен поглед в някои части на платформата и това доста ми помага в работата.  През годините Java се развиваше заедно с нас. Затова е като огледало на всичките проблеми и парадигми, през които премина индустрията.  В отделни случаи става въпрос дори за въртене на 360 градуса (макар в спирала, не в затворен кръг), помислете си само за Project Loom и всички изоставени API, които той ще съживи. Понякога, за да освежа знанията си и да получа алтернативен поглед, издирвам колегите, които програмират на Java с неохота, защото харесват повече други платформи и езици. Така  научавах пръв за различни „еретични“ фреймуърци като Java Poet или Lоmbok.

Като Staff Engineer не просто си сътрудничите, но и подпомагате сътрудничеството между бизнес лидерите и техническите екипи. Какви правила следвате, за да поддържате добрата комуникация?

Софтуерният архитект трябва да бъде авторитет относно нефункционалните изисквания на системата и да се грижи за тяхната правилна идентификация. Няма система, в която всички “illity”-та да бъдат удовлетворени. Това е практически невъзможно. Архитектурата трябва да отговаря на специфични характеристики на продукта. Не съществува и чиста, и стерилна архитектура, винаги става въпрос за диалог и компромис, който архитектът трябва да подпомогне. Софтуерният архитект трябва да бъде и медиатор. Грегор Хоп го оприличава на някой, който постоянно пътува в асансьора на висока сграда, като минава през всичките етажи: от подземието, където бучат сървърите, до мансардата, от където се виждат облаците. В една организация, платформата, продуктовите екипи и групата, която комуникира с клиентите могат да са на различни етажи. Ако този асансьор не съществува, различите етажи на сградата ще заживеят в собствен ритъм и собствен затворен свят. “Неработещият асансьор” може да бъде видян дори в кода на програмните продукти, в частите, пълни с локална оптимизация. Това е пример, в който законът на Конуей ще се прояви в тъмната си страна.

Софтуерният архитект трябва да бъде и медиатор.

Софтуерната архитектура трябва да дава насока, която може да спести на екипите проблеми като затъване в блатото на слабашкия Scrum, за който говори Мартин Фолуър, или пък мениджърския ад, в който различните екипи си подхвърлят горещия картоф един на друг и никой не го желае. Попитахте за комуникация, каква може да бъде комуникацията, ако сме си позволили да стигнем до подобна ситуация? Ние не искаме да подпомагаме подобна комуникация. Ние се стремим  да я предотвратим. 

Проектите трябва да имат изчистена, ясна крайна цел, но дори при поставянето на целта прагматичността в никакъв случай не е порок. За пример мога да дам езерото с костенурките  в кампуса на VMware в Пало Алто, Калифорня. Архитектът, който преди години е правил ландшафтния дизайн на това място, е можел да изравни всичко със земята с булдозери, да засипе дупките с инертен материал, да отсече всички дървета и да започне наново. Вместо това, той е решил да запази много от растенията и естествените форми на терена включително и едно езерце, където по първоначални планове е трябвало да има брокатен шаран. Планът обаче се променя, когато наш колега намира самозаселила се костенурка в един контейнер наблизо. Сега на алеята в кампуса има табела „Внимавайте! Преминават костенурки.”, а в езерото живеят 14 броя от тях. От време на време дори си гледам на web камера, кампусът на VMware един от най-красивите в Силициевата долина. Та така така трябва да се постъпва и при създаването на софтуерна архитектура – не само чрез  намиране на крайна цел, но и с отчитане на вече съществуващите дадености, достижения и с очакването, че промяна винаги ще има и трябва да сме готови да реагираме на нея.  

С какви предизвикателства се сблъсква един Java разработчик в ежедневието си? Какъв технологичен стек използвате? По какви проекти работите в момента? 

Въпросът Ви е относно специфичните проблеми на Java разработчиците, нещата се промениха много през последните години. Слава Богу, вече не ми се налага да се боря с йерархични classloader-и и EAR файлове. За нови версии чакаме по 6 месеца, а не 5 години, както с Java 7.  

Много колеги по различни причини са „заседнали“ със стари версии на JDK и това едно от най-честите оплаквания. При нас повечето проекти са под JDK 11 и в момента сме в процес на преход към на JDK 17, последната LTS версия. Имаме добри pipeline-и и това ни дава сигурност, че евентуалните несъвместимости ще бъдат открити навреме.  

Производителността на Java е често споменавана от начинаещите колеги, които в последствие обикновено откриват, че проблемите им идват от лош код или лош системен дизайн, а не от платформата. Все пак е истина, че въпреки всички оптимизации, HotSpot не може да достигне компилирания код на C++, тук е добре да се следи развитието на Spring Native за GraalVM.

Друг „традиционен“ проблем в Java света е по-трудната инкрементална синхронизация по време на разработка. Java решенията работят с по-тежък стек, услугите се рестартират по-бавно.  Ако работя с Node.js или Python, аз мога да вляза в сървъра, който тествам и директно да „пипна“ там, без да рестартирам нищо, в Java това е невъзможно, без да се използват екзотични решения като JRebel или Spring Boot Devtools. Поголовната „докеризация“ и увеличаване броя на услугите, които разработваме в рамките на продуктите усложни още картината, но две неща са ясни. Първо, екипите с по-добра култура на автоматизирано тестване на кода са много по-продуктивни. Второ, цената за неправилно поставените архитектурни демаркационни линии се вижда точно при тестването.

Относно технологичния стек – това е важен въпрос, но в никакъв случай не бива да се надценява. Нека отново дам строителен пример. Тухлите или изолацията от добър производител не правят задължително една къща стабилна и здрава. В момента платформата ни се състои от множество малки услуги, базирани на Spring Boot. Контейнерите ни отиват в Kubernetes. Скелетът на проектите ни се съставя от собствен engine за шаблони. Така може да се започне от нулата малък сървис, който да се интегрира с цялостния workload,  без да е необходимо да се минават от начало всички стъпки за интеграция с решенията ни за мониторинг, локализация, кеш, телеметрия, брокера на събщения, базата от данни. За разлика от други подобни решения, имаме възможност и за обновление на шаблона във вече съществуващите услуги.

От къде черпите нова информация за случващото се в света на технологиите – подкасти, книги, медии и прочие?

За новини използвам Slashdot и InfoWorld. Чета всичко на Мартин Фаулър (остана ни само четенето, след като той обяви, че изпитва паника всеки път преди да води лекция и повече няма да се явява публично). 

Във VMware всеки разполага със собствен бюджет за образование, който може да употреби, както желае. С този бюджет ходя на конференции по свой избор, а  последното, за което го използвах, беше един bootcamp с шаблони за дистрибутирани данни на Крис Ричърдсън. 

Тъй  като напоследък водя доста интервюта за работа, започнах да научавам много и от колегите, които интервюирам.  

Какъв съвет бихте дали на програмистите, които тепърва стартират своята кариера и биха искали да достигнат Вашето ниво?

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

Как се справяте с work-life баланса? Имате ли конкретни правила, които следвате?

Много ми харесва аналогията, дадена от нашият бивш изпълнителен директор Пат Гелсингер (сега изпълнителен директор на Интел) който нарича този феномен не „баланс“, а „жонглиране“ между три неща: работата, личния живот и вярата. Защо жонглиране, а не баланс: има моменти, когато едната страна в живота ни се нуждае повече от внимание и трябва да направим компромис с останалите. Балансът предполага нещо статично, а жонгльорът може и да залитне малко, но това е част от играта.

За всеки човек трудностите са различни. Моето лично предизвикателство е голямото ми любопитство. Когато работех в стартъпа, проблемът ми беше, че често нямах достатъчно информация, за да удовлетворя любопитството си, а сега е обратното, заобиколен съм от множество интересни проекти, всеки екип желае да демонстрира и покаже нещо интересно. Важен е опитът и разумната преценка.

В този смисъл много е важно умението да се казва „не” – както на себе си, така и на другите.  Да се казва „не”, когато те канят на срещи, където си излишен. Да се казва „не” на работата. Необходимостта да се поставят граници е важна, както в софтуерната архитектура, така и в личния живот.    

]]>
Е-правителство – трябват още 1.5 млрд. лева до 2030 г.? https://devstyler.bg/blog/2020/08/11/e-pravitelstvo-tryabvat-oshte-1-5-mlrd-leva-do-2030-g/ Tue, 11 Aug 2020 09:07:15 +0000 https://devstyler.bg/?p=33702 ...]]> Поне 1.5 млрд. лева ще са необходими, за да има България функционално електронно правителство. Това става ясно от документ със заглавие “Приоритет № 10 “Институционална рамка” на Националната програма за развитие България 2030”, публикуван в Портала за обществени консултации на Министерски съвет.

Очаква се тези 1.5 млрд. лева да бъдат похарчени за цифровизирането на администрацията и свързването на отделни системи, нови електронни услуги за гражданите и бизнес, мрежова и киберсигурност, борба с корупцията и др.

По предварителни данни до момента в проекти, свързани с изграждане на електронно правителство са вложени около 2 млрд. лева. Сумата е изразходвана за периода от 2002 до 2016 г., което средно може да се определи като около 150 млн. лева годишно – общо национално и европейско финансиране. Данни за това са налични на страницата на Българска стопанска камара в рубриката “Стига вече”. В нея за сравнение се отбелязва, че за електронното правителство на сочената за пример Естония са похарчени около 25 млн. евро. От тази сума 70% са вложени в хардуер. Известно е също, че в проекта са използван безплатен софтуер с отворен код.

Все пак, хубавото, че който има желание може да даде своето мнение относно електронното правителство и Националната програма за развитие България 2030.

]]>
Целта ни е до 2027-2030 г. над 90% от учебното съдържание да бъде електронно https://devstyler.bg/blog/2020/06/15/nad-90-procenta-elektronno-uchebno-sadarzhanie-do-2030/ Mon, 15 Jun 2020 10:20:36 +0000 https://devstyler.bg/?p=31706 ...]]> Целта ни е до 2027-2030 г. над 90% от учебното съдържание да бъде електронно, безплатно и разработено от учителите, това споделя в интервю министърът на образованието и науката Красимир Вълчев. Според министър Вълчев, българските учители са направили революционен скок с прилагането на обучението в електронна среда. Какви са предизвикателствата пред министерството? Как ще бъдат обучавани учителите? Защо преподавателите ще бъдат винаги необходими? Вижте цялото интервю.

Министър Вълчев, Вие сте патрон на конкурса “Дигитални новатори в образованието”, организиран от БАИТ (Българска асоциация за информационни технологии). Защо тази инициатива е важна за целия образователен сектор?

Новото десетилетие ще е на дигитализация на образованието. Факт е, че днешните деца учат с образи. Много по-лесно е да се провокира любопитството им чрез електронни устройства, а това променя концепциите на образователните системи. Класната стая на 21 век ще е съчетание от умения, иновации и технологии. Ролята на учителя вече не е на лектор, а на ментор – на този, който трябва да поведе детето да се ориентира правилно в морето от информация. Затова наша цел е да имаме подготвени за тези промени учители, които освен да обучават, ще могат и да създават дигитално съдържание. С обучението в електронна среда българските учители направиха революционен скок. Беше забележително нивото на професионализъм на учителите в трудната ситуация, в която се намираме. Неоспоримо е, че учителят е в центъра на образователния процес, неговият труд е неоценим. Затова смятам, че подобни инициативи, които стимулират учителите и заявяват тяхната значимост в обществото, са важни.

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

За нас беше предизвикателство да стартираме електронното обучение. Системата и учителите бяха изправени пред изцяло нова и неочаквана ситуация, към която трябваше да преминат за три дни. Тези подготвителни дни и първите дни от обучението в електронна среда бяха свързани с много допълнителна работа – избор и регистрация в електронни платформи на всички, избор и подготовка на ресурси, създаване на електронни групи за комуникация с родителите, създаване на изцяло нова организация на учебния процес. Обучението в електронна среда беше ефективно в много голяма част от училищата, благодарение на обединените усилия на всички участници в процеса – директори, учители, родители, ученици. В хода на обучението се подобри организацията и ефективността.

Каква е обратната връзка от страна на учители, ученици и родители по отношение на дистанционното обучение по време на извънредното положение у нас?

Училищата и учителите реагираха изключително бързо, отговорно и  професионално и показаха, че на тях може да се разчита. Родителите се ангажираха много, което помогна за ефективното обучение в електронна среда. Ключовата роля бе на учителите и на родителите. Върху родителите също имаше натоварване, защото голяма част едновременно работят от вкъщи. Освен това те са ангажирани с осигуряване на условия за ефективно учене. Направихме голяма крачка към по-добро взаимодействие между родителите и учителите. Класната стая влезе в дома. Родителят влезе в класната стая. Стана помощник на учителя. Ангажира се с осигуряването на организацията на обучението. Родителите казват, че сега имат по-ясен поглед върху учебния процес, че знаят повече за учебното съдържание, както и за трудностите на децата си.

Голяма част от родителите заявяват, че разбират по-добре колко отговорна е учителската работа и че след провеждането на обучението в електронна среда са започнали да изпитват по-голямо уважение към учителите.

Какви са следващите стъпки, свързани с налагането на дистанционното/онлайн обучението като част от учебния процес у нас?

Следващите стъпки включват обучение на учителите за създаване на електронни ресурси. Ще им предоставим инструменти за изготвяне на тези ресурси, ще има и заплащане на учителите за този авторски продукт. Предстои напасване спрямо учебните програми на тези ресурси, като крайната цел е да имаме безплатни електронни уроци, изготвени от учители. Голяма част от тези стъпки са заложени в проекта „Образование за утрешния ден“, който предстои да стартира. В следващите години инвестициите в електронно обучение няма да бъдат толкова в платформи, колкото в кабинетите, които трябва да се електронизират. Със средства от национална програма ще инвестираме в класни стаи, които ще са модерна СТЕМ среда за обучение. До края на това десетилетие основните образователни ресурси за учениците трябва да бъдат електронни. Целта ни е до 2027-2030 г. над 90% от учебното съдържание да бъде електронно, безплатно и разработено от учителите.

Предвиждате ли проекти за допълнително обучение на учителите, така че да се чувстват по-уверени и да използват повече нови технологии?

Значителна част от учителите са преминали такива квалификации, въпреки че обученията за работа чрез информационни технологии и създаване на електронно съдържание тепърва предстоят по проекта „Образование за утрешния ден”. В него са включени работа с електронни платформи и ресурси, използването на иновативни методи на преподаване и най-вече на проектно-базираното обучение.

Какво е необходимо, за да може всяко училище в страната да разчита на дистанционното обучение като допълваща или алтернативна форма в случай на нужда? Останаха ли училища, които се нуждаят от компютърна техника?

През последните години много училища започнаха да работят с електронни платформи. Ние сме осигурили достъп до интернет, до електронни платформи и електронни дневници във всички училища в страната. Министерството на образованието и науката създаде и Национална електронна библиотека за споделяне на образователни ресурси.

Министерския съвет ще предложи промени в Закона за предучилищното и училищното образование, с които вместо грипни ваканции да бъде въведено дистанционно обучение по подобие на действащото в момента. Целта е да не се губи учебно време, когато има грипни ваканции, особено ако те са повече от два-три дни.

Защо е важно да се инвестира в образованието?

В настоящите времена на изпитания обществото ни разбра, че учителят ще бъде винаги необходим. Общуването в класната стая между учителите и децата е незаменимо. Учителят не обучава, а възпитава – той открива нови хоризонти, предизвиква, поощрява, помага на децата да изграждат своя характер. Образованието е най-ценният капитал, а знанието – най-важната инвестиция. Стъпките по пътя на знанието са бавни и трудни, но винаги дават резултат. За да имат българските деца добро бъдеще, трябва да инвестираме в тяхното образование – да ги направим знаещи и можещи личности, които сами ще определят своя път.

]]>
Проучване цели да подобри процесите с отворените данни и е-управлението https://devstyler.bg/blog/2020/04/28/prouchvane-celi-da-podobri-procesite-s-otvorenite-danni-i-elektronnoto-upravlenie/ Tue, 28 Apr 2020 16:34:09 +0000 https://devstyler.bg/?p=29885 ...]]> Като част от проекта “Отворените данни и гражданското участие” по Оперативна програма “Добро управление”, НПО “Линкс” и Държавна агенция “Електронно управление” съставиха анкета-проучване, която има за цел да даде светлина в процесите, свързани с отворените данни в държавата.

Участието на различните граждани, бизнеси и неправителствени организации ще бъде от голямо значение за подобряването на изпълнението на мониторинг на различните политики и законодателство. Освен това ще е от значение за получаването на обратна връзка и анализиране на степента на информираност и използваемост на отворените данни в страната.

Отворените данни в една държава могат да послужат като чудесен проводник на доброто усвояване на демократичните процеси, прозрачността в управлението и заздравяване или изграждането на гражданско общество.

Рени Борисова от отдел “Данни” към ДАЕУ сподели, че проучването е насочено към граждански и бизнес организации.

Решихме да обърнем фокуса и да ангажираме граждани и бизнес – да проверим от какви данни имат нужда те. При всички положения смисълът на проучването е да достигне до направата на промени, свързани с политиката на отворените данни. Чрез информацията, която това проучване ще ни предостави ние ще можем да предоставим услугите и информацията с по-добро качество,” сподели Рени Борисова.

Тя допълни, че имайки предвид огромните данни, с които разполага държавата, то трябва да се наблегне на качеството на тези, от най-голяма необходимост сред ползвателите.

Налага се в част от данните да поработим с колеги от отделните администрации, за да може да се направи структура и модел. Също така трябва да се доуточни съдържанието на информацията и форматите, в които да се предоставя тя. Целим да не се налагат допълнителни трансформации, а данните да са с такава достъпност, че да е лесно хората да се сдобиват с тях за различни цели,” обясни пред DevStyleR Рени Борисова.

От своя страна, управителят на НПО “Линкс”, Теодора Гандова ни сподели, че колкото повече данни има, толкова повече граждани ще могат да бъдат одитори от своя дом.

Ако имат необходимите умения, те могат да свалят тези данни и да направят статия или блог. Дори чрез натиск, институциите ще бъдат принудени да отговорят относно даден проблем или нещо, което не е както трябва. Когато много хора имат достъп до много данни, това би позволило на всички ни да виждаме от различни ъгли процесите в администрациите на държавата. Това е важно за демокрацията ни и за съществуването ни като общество,” заяви Теодора Гандова.

Въпросникът, може да видите Тук

]]>