is 'n internasionale beweging wat professionele kompetisies vir jongmense onder die ouderdom van 22 reël.
Die internasionale finaal word elke twee jaar gehou. Vanjaar was die finale venue (die laaste eindstryd was in 2017 in Abu Dhabi, die volgende een sal in 2021 in Sjanghai wees).
WorldSkills Championships is die wêreld se grootste kampioenskappe van professionele vaardighede. Hulle het met blouboordjie-beroepe begin, en in onlangse jare is al hoe meer aandag gegee aan "beroepe van die toekoms", insluitend IT-dissiplines, waarvoor 'n afsonderlike reuse-kluster by die kampioenskap in Kazan toegeken is.
In die IT-blok is daar 'n bevoegdheid ('n spesifieke "sport") genaamd "IT Software Solutions for Business".
In elke kompetisie is die toegelate lys gereedskap wat gebruik word beperk. En as, byvoorbeeld, vir "landskapontwerp" die lys van moontlike gereedskap beperk is (natuurlik, sonder om 'n eksplisiete vervaardiger of kleur aan te dui), dan in die bevoegdheid "Sagteware-oplossings vir besigheid" die lys van aanvaarde tegnologieë wat deelnemers kan gebruik is streng beperk, wat spesifieke tegnologieë en spesifieke platforms (.NET en Java met 'n spesifieke stel raamwerke) aandui.
Die posisie van 1C oor hierdie kwessie is soos volg: inligtingstegnologie is 'n baie dinamiese area, nuwe tegnologieë en ontwikkelingshulpmiddels verskyn voortdurend in die wêreld. Uit ons oogpunt is dit korrek om spesialiste toe te laat om die gereedskap te gebruik waarmee hulle wil en gewoond is om te werk.
In die herfs van 2018 het die WorldSkills-bestuur ons gehoor. Nou moes ons die metodologie toets om nuwe tegnologieë by kompetisies in te sluit. Dit is nie eenvoudig nie.
Die 1C:Enterprise-platform is by die infrastruktuurlys van die kampioenskap in Kazan ingesluit en 'n eksperimentele platform vir IT-sagteware-oplossings vir besigheidsandbak is georganiseer.
Neem asseblief kennis dat die amptelike taal van die kampioenskap Engels is. Alle materiaal met die resultate van die oplossing van take (bronkodes, gepaardgaande dokumentasie, sagteware-koppelvlakke) moes ook in hierdie taal versend word. Ten spyte van die twyfel van sommige mense (steeds!), kan jy in Engels in 1C skryf.
9 jong ouens van 8 lande (Filippyne, Taiwan, Korea, Finland, Marokko, Rusland, Kazakhstan, Maleisië) het aan die kompetisie by hierdie terrein deelgeneem.
Die jurie - 'n span kundiges - is gelei deur 'n kenner van die Filippyne, Joey Manansala.
Kenners van Finland, die VAE, Costa Rica, Korea, Rusland en Taiwan is verteenwoordig.
Afsonderlik neem ons kennis dat deelnemers van Rusland (Pavkin Kirill, Sultanova Aigul) en Kazakstan (Vitovsky Ludwig) besluit het om die 1C:Enterprise-platform as deel van die kompetisie te gebruik. Die res van die deelnemers het .NET vir rekenaars en Android Studio vir mobiele ontwikkeling gebruik. Dit is interessant dat die deelnemers wat 1C gekies het, baie jonk is (Kirill is 'n student by 'n skool in Stavropol, hierdie jaar het hy die 11de graad betree, Aigul is 'n universiteitstudent, Kazan, Tatarstan), terwyl hul teenstanders baie meer ervare was ( byvoorbeeld, 'n deelnemer van Korea - wenner van die 2013 WorldSkills-kampioenskap in Leipzig; almal het ondervinding om aan WorldSkills deel te neem en etlike jare se professionele ondervinding in die bedryf).
As in ag geneem word dat die deelnemers tydens die kompetisie verskeie moderne tegnologieë gebruik het, het ons die kans gehad om die 1C:Enterprise-platform in werklike gevegstoestande te toets, om beide die kwaliteit van die oplossings wat met sy hulp verkry is, en die spoed van ontwikkeling wat met die gebruik daarvan behaal is, te vergelyk.
Afsonderlik neem ons kennis dat deelnemers in die raamwerk van die spesiale IT Sagteware-oplossings vir Besigheid-sandbox-platform dieselfde take voltooi het as deelnemers aan die hoof-IT Sagteware-oplossings vir Besigheid-platform.
Die taak self is 'n komplekse taak om 'n sekere besigheid te outomatiseer; hierdie jaar was die voorbeeld van 'n besigheid die fiktiewe maatskappy KazanNeft.
legende
Kazan Oil is een van die grootste olie-ondernemings in die Republiek van Tatarstan, wat as 'n nasionale markspeler en 'n internasionaal erkende handelsmerk op hierdie gebied funksioneer. Die hoofkantoor van die maatskappy, wat spesialiseer in veldeksplorasie, produksie, produksie, raffinering, vervoer en verkoop en verspreiding van olie, petroleumprodukte en aardgas, is in Kazan (Rusland) geleë.
Aangesien die maatskappy 'n strategie van vinnige uitbreiding en skepping van nuwe kantore regdeur Rusland implementeer, het die maatskappy se bestuur besluit om nuwe besigheidsoutomatiseringsagteware bekend te stel wat daarop gemik is om sekere bedrywighede in stand te hou en te bestuur.
Kampioenskap toestande
Take is aan deelnemers gegee in die vorm van modules (sessies) met die vereiste om dit in 'n beperkte tyd te voltooi. Daar was altesaam 7 modules. Drie sessies om op 'n lessenaar op te los – 2.5 uur elk. Drie sessies - kliënt-bediener ontwikkeling, waar die kliënt 'n mobiele toepassing was, en kommunikasie tussen die kliënt en bediener is uitgevoer via WEB-API. Dit het 3.5 uur geneem. Laaste sessie – take oor omgekeerde ingenieurswese van bestaande sagteware, 2.5 uur. As deel van omgekeerde ingenieurswese moes deelnemers, gebaseer op die inligting wat aan hulle verskaf is, die struktuur van die toepassingdatabasis ontwerp (deur 'n ER-diagram te bou), scenario's vir die gebruik van die stelsel te ontleed (deur 'n gebruiksgevaldiagram te bou), en ook ontwikkel en ontwerp die koppelvlak van die sagteware-oplossing volgens die verskafde funksionele vereistes.
Die belangrikste ontwikkelingsplatforms wat gebruik is, was .NET (C#) en Java (insluitend Android Studio vir mobiele ontwikkeling). Die eksperimentele SandBox het .NET, Java en 1C:Enterprise weergawe 8.3.13 gebruik.
Aan die einde van elke sessie het die kenners die resultaat beoordeel - 'n klaargemaakte werkbare projek wat die take wat aan die begin van die sessie gestel is, implementeer.
Die eienaardigheid van take is hul "vitaliteit" - baie vereistes en beperkte tyd. Die meeste van die probleme is nie spesiale Olimpiade-probleme nie, maar is baie na aan werklike industriële probleme – spesialiste staar dit elke dag in die gesig. Maar daar is baie take, en tyd is beperk. Die deelnemer moet die maksimum aantal probleme oplos wat die grootste voordeel vir die onderneming sal inhou. Dit is glad nie 'n feit dat 'n komplekse taak uit 'n algoritmiese oogpunt meer gewig as 'n elementêre een sal hê nie. Byvoorbeeld, die skep van 'n funksionerende rekeningstelsel van drie tabelle is belangriker vir 'n besigheid as 'n pragtige rapporteringsvorm met komplekse algoritmes, wat heeltemal onnodig is sonder hierdie tabelle.
Ons het die wenner van die kompetisie, 'n deelnemer van Rusland, Kirill Pavkin, gevra om ons meer te vertel oor wat die take was en hoe hy hul oplossing benader het.
Hieronder is 'n beskrywing van die taak, Kirill se eie storie oor hoe hy die taak opgelos het. Ons het ook vir Vitaly Rybalka, 'n 1C-werknemer en een van die IT Solutions for Business Sandbox-kundiges, gevra om kommentaar te lewer oor Kirill se oplossings.
As deel van die opdrag was dit nodig om die aktiwiteite van verskeie tipes gebruikers te outomatiseer:
- Verantwoordelik vir die boekhouding van maatskappybates
- Verantwoordelik vir ongeskeduleerde herstelwerk en geskeduleerde instandhouding van maatskappybates
- Aankoopbestuurders vir komponente en verbruiksgoedere
- Olie-eksplorasie- en olieproduksie-afdelings
- Topbestuur het analitiese verslae nodig gehad
Sessie 1
Uit die oogpunt van bates (byvoorbeeld 'n voertuigvloot) was dit nodig om hul rekeningkunde te implementeer (vestiging van nuwes, redigeer huidiges), vinnige soektog en verskeie soorte filters vir die vertoon van inligting, die verskuiwing van bates tussen die Maatskappy se afdelings en groepe bates self. Hou 'n geskiedenis van sulke bewegings en verskaf ontledings daaroor in die toekoms. Baterekeningkunde is hoofsaaklik vir mobiele gebruikersgroepe geïmplementeer.
Cyril: 'n Interessante subtaak was die implementering van knoppies in die batelys. Om dit op te los, het ons 'n dinamiese lys gebruik: ons skryf 'n arbitrêre versoek, en wanneer ons data op die bediener ontvang, ken ons navigasieskakels toe aan beelde van die beeldbiblioteek aan die vereiste velde.
Foto's kan volgens konvensie op twee maniere aan 'n bate geheg word: neem 'n foto (multimedia) en kies uit die gallery (lêerkeusedialoog).
Sommige vorms moes oorgeteken word wanneer die skerm gedraai is:
Wanneer ons skermparameters verander, verander ons die sigbaarheid van knoppiegroepe.
Vermaaklike maar eenvoudige take sluit filters in 'n dinamiese lys, soektog in twee velde (nommer en naam) en generering van 'n bate-reeksnommer in.
Deskundige kommentaar: vanuit die oogpunt van die oplossing op die 1C:Enterprise-platform is die taak baie duidelik. Benewens die werklike skepping van die mobiele toepassing, was dit nodig om te sorg vir die oordrag van data vanaf die DBMS "bediener" (MS SQL op die lessenaar) na die mobiele toepassing en terug. Vir hierdie doel is die meganismes van eksterne databronne en http-dienste in die lessenaar-“proxy-toepassing” gebruik. Vir die mobiele platform self het die vertoon van foto's in 'n dinamiese lys verhoogde kompleksiteit getoon.
Sessie 2
Dit was nodig om herstelbestuur vir die Maatskappy se bates daar te stel. As deel van hierdie taak was dit nodig om 'n lys van versoeke vir herstelwerk (deur departemente en groepe) by te hou, die prioriteite vir die dringendheid van herstelwerk in ag te neem, 'n herstelskedule in ooreenstemming met prioriteite te beplan, die nodige komponente te bestel en te neem bestaandes in ag te neem. 'n Interessante subtaak was dat sommige komponente 'n vervaldatum gehad het; as 'n onderdeel reeds vir 'n gegewe bate bestel is en die sperdatum daarvan het nie verstryk nie, dan is dit vir hierdie bate nie nodig om dieselfde onderdeel weer te koop nie. Die herstelkoppelvlak is ontwikkel vir die lessenaarkomponent van die maatskappy se sagteware.
Dit was ook nodig om 'n nie-triviale magtigingsvorm vir twee rolle te skep: die verantwoordelike persoon en die diensbestuurder. Die eienaardigheid is dat jy na magtiging outomaties een van die rolle moet kies.
Die lysvorm wat vir die verantwoordelike persoon beskikbaar is, word hieronder aangebied:
Cyril: Slegs die uitlig van hangende diensversoeke kan hier uitgelig word. Opgelos deur voorwaardelike formatering in 'n dinamiese lys.
Deur op die knoppie onderaan die skerm te klik, kan die gebruiker na die volgende vorm gaan:
Daar is niks ingewikkeld uit 'n 1C-oogpunt in hierdie vorm nie.
Die vorm beskikbaar vir die diensbestuurder is hieronder:
Hierdie vorm word gesorteer volgens prioriteit en datum van versoek. Deur op die knoppie hieronder te klik, kan die gebruiker na die vorm van die geselekteerde versoek gaan:
Benewens foolproofing, het hierdie vorm voorgestel dat 'n lys onderdele vir herstelwerk geïmplementeer word. Die subtaak is interessant omdat die dele 'n vervaldatum het. Dit beteken dat indien 'n noodgeval reeds met hierdie bate plaasgevind het en 'n onderdeel daarvoor bestel is, waarvan die geldigheidstydperk nie verstryk het nie, dit hergebruik kan word. Dit moet aan die gebruiker gewys word.
Deskundige kommentaar: hier het Kirill self die aksente korrek geplaas. Uit die oogpunt van implementering op die 1C:Enterprise-platform is daar niks uiters ingewikkeld nie. 'n Noukeurige ontleding van die voorwaardes vir rekeningkunde en gebruik van onderdele en bekwame implementering van die taak as geheel was nodig. Boonop was dit nodig om diensversoeke behoorlik aan te teken. Die grootste probleem was slegs die tyddruk van 2.5 uur.
Daarbenewens, soos in mobiele ontwikkeling, moes die deelnemer bekwaam data van 'n eksterne DBBS (MS SQL) bekom.
Sessie 3
Vir instandhouding (instandhouding) is voorgestel om 'n langtermynbeplanningsdiens te implementeer. 'n Interessante kenmerk hier was die vereiste om 'n onderhoudskedule vir bates volgens tydsberekening te skep - byvoorbeeld elke tweede maand op die 3de. Net so, volgens een of ander kwantitatiewe aanwyser - byvoorbeeld volgens 'n motor se kilometerteller (olievervanging elke 5000 20000 km, bandvervanging elke XNUMX XNUMX km). Die instandhoudingsbestuurder moes 'n gerieflike mobiele toepassing ontvang het wat 'n lys van agterstallige, huidige en voltooide instandhouding vir 'n bepaalde tydperk dinamies vertoon. Boonop moes elke tipe onderhoud volgens spesiaal ooreengekome reëls in kleur geverf word. Die mobiele toepassing was veronderstel om die skep van nuwe instandhoudingskedules te verseker en die nasien van dié wat reeds direk in die werkswinkels voltooi is, met vinnige opdatering van hierdie inligting op die bediener te verseker.
Cyril: Daar is twee soorte herstelwerk: tydgebaseerd en lopiegebaseer. Veranderlikheid word binne elkeen toegelaat. Volgens die plan moet herstelwerk byvoorbeeld elke Vrydag, die 13de van die maand of elke 20,000 XNUMX kilometer plaasvind. 'n Taak word as voltooi beskou as daar 'n vinkje regs daarvan is.
'n Voorwaarde is gestel om take in die lys te sorteer. Elke lyn moet ook in kleur uitgelig word, afhangende van die toestande.
Deur op die knoppie hieronder te klik, kan jy 'n nuwe diensplan skep:
Die vereiste velde word vertoon afhangende van die gekose grafiektipe. As ons 'n weeklikse tydskedule gekies het, sal ons twee velde gewys word: die weeknommer en die dag van die week. Byvoorbeeld, op Dinsdae elke 3 weke.
Deskundige kommentaar: soos in die vorige mobiele ontwikkeling op die 1C:Enterprise-platform, word die taak hier wêreldwyd in 2 komponente verdeel - kommunikasie met die "bediener" via web-api en bekwame vertoon van 'n dinamiese lys met voorwaardelike ontwerp en filtering (seleksie) van data. Daarbenewens was dit interessant om die vereiste te implementeer om rekening te hou met herstelwerk, beide volgens tydperk en volgens kwantitatiewe aanwyser.
Sessie 4
Vir komponente en verbruiksgoedere was dit nodig om voorraad, beplan uitgawes en toekomstige aankope in ag te neem. Boonop het joernaalrekeningkunde hier verskyn, maar nie vir alle goedere nie. Dit alles moes binne verskeie pakhuise bestuur word, insluitend ontvangs, uitgawes en beweging. Volgens die bepalings van die taak was dit nodig om beheer van saldo's te verseker en konflik te vermy wanneer met huidige aandele gewerk word. Aankoopbestuurders werk in die rekenaarweergawe van die sagteware.
Die hoofvorm word hieronder getoon:
Cyril: Benewens sortering vanaf die toestand, is voorgestel om die gebruiker die vermoë te gee om ewekansig te sorteer. Op 1C hoef jy nie eers daaraan te dink nie. Die veld met die hoeveelheid onderdele moet in groen uitgelig word vir fakture.
In hierdie sessie is hulle gevra om die oorblywende goedere in pakhuise te beheer. Dus, die ooreenstemmende boodskap moet vertoon word wanneer jy probeer om die faktuur uit te vee. Hier onthou ons die platformspesialis-eksamen. Die vorm van die faktuur is soos volg:
Elke onderdeel het 'n eienskap wat bepaal of dit aan 'n spesifieke bondel toegewys moet word. Vir sulke onderdele is dit noodsaaklik om die joernaalnommer in alle dokumente aan te dui. Dit is 'n bykomende meting wanneer onderdele-reste gemonitor word. Hulle kan ook tussen pakhuise geskuif word:
Die vorm verskil slegs van die vorige een deurdat jy in plaas van die kliënt die pakhuis moet aandui waaruit die aflewering gedoen sal word. Die keuselys vir die bondel word outomaties saamgestel nadat die onderdeel gekies is. Die gebruiker kan 'n verslag oor onderdelesaldo's genereer:
Hier kan ons die oorblywende goedere in die geselekteerde pakhuis sien. Die merkblokkies aan die regterkant van die pakhuis laat jou toe om filtering en sortering op te stel. Die lys het nie 'n eksplisiete verdeling deur loting vir daardie dele waarvoor dit vereis word nie. Die saldo's vir elke bondelnommer van die geselekteerde onderdeel kan besigtig word deur die navigasieskakel aan die regterkant te gebruik.
Deskundige kommentaar: in hierdie sessie (module) het joernaalrekeningkunde vir die eerste keer verskyn. Daar is van deelnemers verwag om rekenskap te gee van verbruiksgoedere en goedere nie net deur hulself nie, maar ook per bondel. Oor die algemeen is die taak perfek vir die 1C:Enterprise-platform – maar dit moes alles van nuuts af ontwikkel en in 2.5 uur voltooi word.
Sessie 5
In die vyfde sessie is ons die funksionaliteit van putbestuur toegewys. Vir eksplorasiegroepe was dit nodig om 'n mobiele toepassing te skep wat rekening sou hou met olie- of gasproduksieboorgate. Hier was dit nodig om 'n lys van huidige putte van die bediener te ontvang en die geselekteerde put grafies volgens lae (grond, sand, klip, olie) te vertoon, met inagneming van die dieptes van elke laag. Daarbenewens moes die toepassing die opdatering van inligting oor die put en die byvoeging van nuwe putte toelaat. Vir hierdie toepassing stel die kliënt spesiale bedryfstoestande in vanlyn en aanlynmodusse (beheer van kommunikasie met die bediener) - kontroleer kommunikasie met die bediener elke 5 sekondes en verander die funksionaliteit van die toepassing, afhangende van die beskikbaarheid van die bediener.
Cyril: Wanneer jy 'n put kies, word 'n staafgrafiek vertoon wat die lae tot by die olie- of gasafsettings uitlig. Vir elke laag word sy naam, kleur en voorkomsreeks gestoor. Weens die ontwerpkenmerke help die diagramme wat in die platform ingebou is nie, maar die sigbladdokument hanteer die taak perfek. Putte kan geskep en gewysig word:
Afgesien van veelvuldige onfeilbare beskerming, was daar niks interessant aan hierdie vorm nie.
Vervolgens is voorgestel om die verbinding met die bediener te beheer. Ons probeer om elke 5 sekondes te koppel. As dit nie werk nie, beperk ons die funksionaliteit van die toepassing en vertoon 'n boodskap.
Deskundige kommentaar: Die taak van hierdie sessie is hoofsaaklik interessant vanweë die grafiese vermoëns daarvan. Deelnemers wat die 1C:Enterprise-platform gebruik het, het dit op twee verskillende maniere opgelos - sommige met 'n diagrammeganisme, ander met 'n sigbladdokument. Elke metode het sy voor- en nadele. As deel van die besluit by die WorldSkills-kampioenskap was tyd die sleutel (onthou weer die tydsbeperking). 'n Aparte interessante taak is om die bediener elke 5 sekondes te ping en die gedrag van die mobiele toepassing te verander na gelang van die beskikbaarheid of onbeskikbaarheid van die bediener.
Sessie 6
Daar is voorgestel om 'n werkspasie vir topbestuur te skep - Dashboard. Op een skerm was dit nodig om die algemene prestasie-aanwysers van die maatskappy vir 'n bepaalde tydperk in grafiese en tabelvorm te vertoon. Die hoofvorm is die kosteverslag:
Benewens die Dashboard, was dit nodig om die verspreiding van onderdele vir bateherstelwerk te implementeer deur EIEU/LIFO/“Goedkoopste gaan eerste”-afskryfmetodes te gebruik.
Tydens verspreiding is bondelrekeningkunde in ag geneem, balansbeheer en beskerming teen ongemagtigde gebruikersaksies (“fool protection”) is gebruik.
Cyril: Om op te los, is tabelle van waardes met sagtewaregenerering van kolomme gebruik, aangesien daar 'n arbitrêre aantal daarvan kan wees:
- Die eerste tabel is verantwoordelik vir die totale koste van departemente per maand. Die mees onwinsgewende en winsgewende afdelings word onderskeidelik in rooi en groen uitgelig.
- Die tweede tabel toon die duurste en mees gebruikte onderdele vir elke maand. As daar verskeie dele is wat aan die kriteria voldoen, moet hulle in een sel vertoon word, geskei deur kommas.
- Die duurste bates (in terme van onderdelekoste) word in die eerste ry van die derde tabel vertoon. Die tweede reël wys die afdeling waartoe die bate hierbo behoort. As daar twee duurste bates met dieselfde koste is, moet hulle in dieselfde sel vertoon word, geskei deur kommas.
Die diagramme is vertoon met behulp van die ingeboude meganismes van die platform, en programmaties ingevul deur navrae te gebruik.
Daar is ook voorgestel om ondersteuning vir veeltaligheid te implementeer. Die program laai XML-lêers met die lokalisering van koppelvlak-elemente, en die vorm moet herteken word wanneer 'n taal in die aftreklys gekies word.
Wanneer jy op die knoppie in die onderste linkerhoek van die skerm klik, maak die voorraadbestuursvorm oop:
In hierdie vorm begin ons uiteindelik onderdele spandeer op herstelwerk. Hier vind ons eers die onderdele wat ons sal nodig hê om die bate te herstel. Gebaseer op die geselekteerde velde en verspreidingsmetode (EIEU, LIFO of minimum prys), word die passings wat gevind is of 'n boodskap as daar geen passings is nie, vertoon. Jy kan dan die onderdele merk as bedoel om daardie bate te herstel. Balansbeheer is relevant vir die huidige sessie. As ons reeds besonderhede toegewys het, kan dit nie meer gevind word nie.
Deskundige kommentaar: baie interessante sessie. Dit maak die meeste van die vermoëns van die 1C:Enterprise-platform - hier is bekwame werk met virtuele tabelle van akkumulasieregisters, en programmatiese werk met vormelemente (eerste van alles - tabelle, tweedens - opskrifte), en diagramme. En selfs LIFO/EIEU wanneer voorraad, wins/verlies-analise, ens.
Sessie 7
Aan die einde van die taak (sessie 7) het die kliënt sagteware (exe-lêer) verskaf vir projekaktiwiteite en 'n kort video oor die werk daarmee. Dit was nodig om omgekeerde ingenieurswese uit te voer en, op grond hiervan, 2 diagramme te skep: 'n gebruiksgevaldiagram en 'n entiteitsverwantskapdiagram. Daarbenewens is sekere vereistes gestel vir die skep van sagteware in die toekoms - dit was nodig om 'n koppelvlakuitleg volgens hierdie vereistes te skep.
Volgens die kompetisievoorwaardes was slegs MS Visio nodig om diagramme te skep.
Deskundige kommentaar: in hierdie sessie is die vermoëns van die 1C:Enterprise-platform feitlik nie gebruik nie. Diagramme vir die kompetisievoorwaardes is in MS Visio geskep. Maar 'n prototipe van die koppelvlak kan in 'n leë 1C-inligtingsbasis geskep word.
Algemene opmerkings
Aan die begin van elke sessie is voorgestel om data met behulp van 'n SQL-skrif in te voer. Dit was die grootste nadeel van die gebruik van 1C in vergelyking met C#, aangesien ons ten minste 'n halfuur bestee het om data in eksterne databronne te distilleer, ons eie tabelle te skep en rye van eksterne bronne na ons tabelle te skuif. Die res moes net op die Uitvoer-knoppie in Microsoft SQL Studio klik.
Om ooglopende redes is dit nie 'n goeie idee om data op 'n mobiele toestel te stoor nie. Daarom het ons tydens mobiele sessies 'n bedienerbasis geskep. Hulle het data daar gestoor en toegang daartoe verskaf via http-dienste.
Deskundige kommentaar: die 1C/nie-1C-balans is hier interessant - terwyl 1C:Enterprise-programmeerders aansienlike tyd spandeer het om aan 'n eksterne DBMS te koppel (Kirill het dit afsonderlik hierbo genoem), C#/Java (Android Studio vir mobiele ontwikkeling) het tyd aan ander gebiede bestee – koppelvlakke, skryf meer kode. Daarom was die resultate van elke sessie onvoorspelbaar en uiters interessant vir alle kenners. En hierdie intrige het tot die einde gebly – kyk maar na die finale tabel van wenners met die verdeling van punte.
Kirill het die storie klaargemaak :)
Ten slotte moet onthou word dat die uitvoerder nie nodig gehad het om "net die taak volgens die tegniese spesifikasies te programmeer" nie - hy moes die taak ontleed, blokke kies vir die implementering van subtake, dit ontwerp en besluit wat hy presies sou wees in staat is om hieruit te implementeer in die uiters kort toegewese tyd. Al 4 dae moes ek onder erge tydsdruk optree, en elke daaropvolgende sessie van voor af begin. Selfs 'n volwasse spesialis met baie jare ondervinding in die bedryf sal groot probleme ondervind om die opdragte taak vir die sessie 100% binne die toegelate tyd te voltooi.
Die aanvaarde assesseringstelsel verdien spesiale vermelding.
Vir elke sessie ontwikkel die taakskrywers 'n komplekse stelsel van kriteria, insluitend die kontrolering van funksionaliteit, korrekte werking, vereistes vir die toepassingskoppelvlak, en selfs die volg van 'n stylgids wat spesiaal aan die deelnemers verskaf is deur die maatskappy waarvoor hulle hul oplossings ontwikkel.
Die evalueringskriteria is baie fyn gegranuleer - met die totale koste van die sessietaak wat tientalle punte is, kan die nakoming van een of ander kriterium tiendes van 'n punt by die deelnemer voeg. Dit bereik 'n uiters hoë en objektiewe vlak van evaluering van die resultate van elke deelnemer aan die kompetisie.
Bevindinge
Die finale resultate was indrukwekkend.
In ’n bitter stryd het Kirill Pavkin van Rusland, wat die 1C:Enterprise-platform gebruik het, gewen. Kirill is 17 jaar oud, hy is van Stavropol.
Letterlik tiendes van 'n punt het die wenner van sy agtervolgers geskei. Die tweede plek is deur 'n deelnemer van Taiwan ingeneem. Die algehele tabel van die top ses resultate lyk soos volg:
Natuurlik het Kirill gewen danksy sy talent, kennis en vaardighede.
Ons neem egter kennis dat al drie deelnemers wat die 1C:Enterprise-platform as 'n instrument gebruik het by die topvyf ingesluit is - wat 'n onvoorwaardelike bevestiging is van die wêreldvlak van 1C:Enterprise-tegnologie.
Ná die uitslae van die kompetisie is die wenners by die KazanExpo-mediasentrum toegeken; die ouens het suiwer goue medaljes (in ooreenstemming met hul plek) en kontantpryse ontvang. Die ouens het ook sertifikate ontvang wat hulle toelaat om 'n internskap by 1C te ondergaan.
Bron: will.com