Benim adım Dmitry. Ekibimizin Big Data pistinde Urban Tech Challenge hackathon'unda nasıl finallere ulaştığından bahsetmek istiyorum. Hemen şunu söyleyeyim, bu katıldığım ilk hackathon değil, ödül aldığım ilk hackathon da değil. Bu bağlamda, hikayemde bir bütün olarak hackathon endüstrisine ilişkin bazı genel gözlemleri ve sonuçları dile getirmek ve Urban Tech Challenge'ın bitiminden hemen sonra çevrimiçi olarak ortaya çıkan olumsuz incelemelere karşı kendi bakış açımı sunmak istiyorum (örneğin, örnek ).
Öncelikle bazı genel gözlemler yapayım.
1. Pek çok kişinin saf bir şekilde hackathon'un en iyi kodlayıcıların kazandığı bir tür spor yarışması olduğunu düşünmesi şaşırtıcı. Bu yanlış. Hackathon organizatörlerinin kendilerinin ne istediklerini bilmedikleri durumları dikkate almıyorum (bunu ben de gördüm). Ancak kural olarak hackathon düzenleyen şirket kendi hedeflerinin peşinden gider. Listeleri farklı olabilir: bazı sorunlara teknik bir çözüm, yeni fikir ve insan arayışı vb. olabilir. Bu hedefler genellikle etkinliğin formatını, zamanlamasını, çevrimiçi/çevrimdışı, görevlerin nasıl formüle edileceğini (ve formüle edilip edilmeyeceğini), hackathon'da kod incelemesi yapılıp yapılmayacağını vb. belirler. Hem takımlar hem de yaptıkları bu açıdan değerlendiriliyor. Ve şirketin ihtiyaç duyduğu noktaya en iyi şekilde ulaşan takımlar kazanır ve birçoğu, gerçekten bir spor müsabakasına katıldıklarını düşünerek, tamamen bilinçsizce ve tesadüfen bu noktaya gelir. Gözlemlerim, katılımcıları motive etmek için organizatörlerin en azından bir spor ortamı ve eşit koşullar görünümü yaratması gerektiğini, aksi takdirde yukarıdaki incelemede olduğu gibi bir olumsuzluk dalgasıyla karşılaşacaklarını gösteriyor. Ama konuyu saptırıyoruz.
2. Dolayısıyla aşağıdaki sonuç. Organizatörler, hackathon'a kendi çalışmalarıyla gelen katılımcıların ilgisini çekiyor, hatta bazen bu amaçla özel olarak çevrimiçi bir yazışma aşaması bile düzenliyorlar. Bu, daha güçlü çıktı çözümlerine olanak tanır. "Kendi çalışması" kavramı oldukça göreceli bir kavramdır; deneyimli herhangi bir geliştirici, ilk projesinde eski projelerinden binlerce satır kod biriktirebilir. Peki bu önceden hazırlanmış bir gelişme mi olacak? Ancak her durumda, ünlü bir meme şeklinde ifade ettiğim kural geçerlidir:
Kazanmak için bir şeye, bir tür rekabet avantajına sahip olmanız gerekir: geçmişte yaptığınız benzer bir proje, belirli bir konudaki bilgi ve deneyim veya hackathon başlamadan önce yapılmış hazır bir çalışma. Evet, sportif değil. Evet, bu harcanan çabaya değmeyebilir (burada, tüm takıma dağıtılan 3 bin ödül için gece 100 hafta kodlamaya değip değmeyeceğine ve hatta alamama riskiyle karşı karşıya olup olmadığına herkes kendisi karar verir). Ancak çoğu zaman ilerlemek için tek şans budur.
3. Takım seçimi. Hackathon sohbetlerinde fark ettiğim gibi, çoğu kişi bu konuya oldukça ciddiyetsiz yaklaşıyor (her ne kadar hackathonda sonucunuzu belirleyecek en önemli karar bu olsa da). Pek çok faaliyet alanında (hem sporda hem de hackathonlarda) güçlü insanların güçlüyle, zayıfın zayıfla, akıllının akıllıyla birleşme eğiliminde olduğunu gördüm, yani genel olarak anladınız... Sohbetlerde kabaca olan şey budur: Daha az güçlü programcılar hemen kapılırlar, bir hackathon için değerli herhangi bir beceriye sahip olmayan kişiler uzun süre sohbette kalırlar ve keşke birisi kabul ederse ilkesine göre bir takım seçerler. . Bazı hackathonlarda takımlara rastgele atama yapılıyor ve organizatörler rastgele takımların mevcut takımlardan daha kötü performans göstermediğini iddia ediyor. Ancak gözlemlerime göre, motive insanlar genellikle kendi başlarına bir takım buluyorlar; birinin atanması gerekiyorsa çoğu zaman hackathon'a gelmiyor.
Ekibin bileşimine gelince, bu oldukça bireyseldir ve büyük ölçüde göreve bağlıdır. Asgari uygulanabilir ekip kompozisyonunun bir tasarımcı - ön uç veya ön uç - arka uç olduğunu söyleyebilirim. Ancak yalnızca ön uçlardan oluşan takımların kazandığı, node.js'ye basit bir arka uç ekleyen veya React Native'de mobil uygulama yapan ekiplerin kazandığı durumları da biliyorum; veya yalnızca basit düzen yapan destekçilerden. Genel olarak her şey çok bireyseldir ve göreve bağlıdır. Hackathon için takım seçme planım şu şekildeydi: Bir takım kurmayı ya da front-end - back-end - tasarımcı (kendim de front-end'im) gibi bir takıma katılmayı planladım. Ve oldukça hızlı bir şekilde bir python destekçisi ve bize katılma davetini kabul eden bir tasarımcı ile sohbet etmeye başladım. Kısa bir süre sonra, hackathon kazanma deneyimi olan bir iş analisti olan bir kız aramıza katıldı ve bu onun bize katılması konusunu belirledi. Kısa bir toplantının ardından fantastik dörtlüye benzeterek kendimize U4 (URBAN 4, urban four) adını vermeye karar verdik. Hatta telegram kanalımızın avatarına da buna karşılık gelen bir resim koydular.
4. Bir görev seçme. Daha önce de söylediğim gibi rekabet avantajınız olmalı, hackathon görevi buna göre seçiliyor. Buna dayanarak, baktık ve karmaşıklıklarını değerlendirerek iki göreve karar verdik: DPiIR'den yenilikçi işletmelerin kataloğu ve EFKO'dan bir sohbet robotu. DPIiR'deki görev destek sağlayıcı tarafından seçildi, EFKO'daki görev ise benim tarafımdan seçildi çünkü node.js ve DialogFlow'da chatbot yazma deneyimim vardı. EFKO görevi aynı zamanda makine öğrenimini de içeriyordu; makine öğrenimi konusunda çok kapsamlı olmasa da bazı deneyimlerim var. Ve sorunun koşullarına göre bana, makine öğrenimi araçları kullanılarak çözülmesi pek mümkün görünmüyordu. Organizatörlerin bana EFKO'ya ilişkin yaklaşık 100 ürün yerleşimi fotoğrafının (farklı açılardan çekilmiş) ve yaklaşık 20 sınıf düzen hatasının bulunduğu bir veri kümesi gösterdiği Urban Tech Challenge buluşmasına gittiğimde bu duygu daha da güçlendi. Ve aynı zamanda görevi sipariş edenler %90'lık bir sınıflandırma başarı oranına ulaşmak istiyorlardı. Sonuç olarak ML olmadan çözümün sunumunu hazırladım, destekçi kataloğa dayalı bir sunum hazırladı ve sunumları tamamladıktan sonra birlikte Urban Tech Challenge'a gönderdik. Zaten bu aşamada her katılımcının motivasyon düzeyi ve katkısı ortaya çıktı. Tasarımcımız tartışmalara katılmadı, geç cevap verdi, hatta sunumda kendisi hakkında bilgileri son anda doldurdu, genel olarak şüpheler oluştu.
Sonuç olarak, görevi DPiIR'den geçtik ve EFKO'yu geçemediğimiz için hiç üzülmedik, çünkü görev bize en hafif tabirle tuhaf göründü.
5. Hackathon'a hazırlanmak. Nihayet hackathon'a katılmaya hak kazandığımız öğrenildiğinde hazırlıklara başladık. Ve burada hackathon başlamadan bir hafta önce kod yazmaya başlamayı savunmuyorum. En azından, araçları yapılandırmanıza gerek kalmadan ve bir hackathon'da ilk kez denemeye karar verdiğiniz bazı kütüphanelerin hatalarıyla karşılaşmadan hemen çalışmaya başlayabileceğiniz bir standart hazır olmanız gerekir. Bir hackathon'a gelen ve proje yapısını oluşturmak için 2 gün harcayan açısal mühendisler hakkında bir hikaye biliyorum, bu yüzden her şey önceden hazırlanmalıdır. Sorumlulukları şu şekilde dağıtmayı amaçladık: arka sunucu, İnternet'i tarayan ve toplanan tüm bilgileri veritabanına koyan tarayıcılar yazarken, ben node.js'de bu veritabanını sorgulayan ve verileri öne gönderen bir API yazıyorum. Bu konuda önceden express.js kullanarak bir sunucu hazırladım ve react'da bir front-end hazırladım. CRA kullanmıyorum, web paketini her zaman kendim için özelleştiriyorum ve bunun ne gibi riskler oluşturabileceğini çok iyi biliyorum (açısal geliştiriciler hakkındaki hikayeyi hatırlayın). Bu noktada ne tasarlayacağıma dair fikir sahibi olmak için tasarımcımızdan arayüz şablonları veya en azından maketler istedim. Teorik olarak onun da kendi hazırlıklarını yapması ve bizimle koordine etmesi gerekiyor ama bir cevap alamadım. Sonuç olarak tasarımı eski projelerimden birinden ödünç aldım. Ve bu projenin tüm stilleri zaten yazıldığı için daha da hızlı çalışmaya başladı. Dolayısıyla sonuç: bir takımda her zaman bir tasarımcıya ihtiyaç duyulmaz))). Bu gelişmelerle hackathona geldik.
6. Hackathon'da çalışın. Ekibimi ilk kez canlı olarak Merkezi Dağıtım Merkezi'ndeki hackathon açılışında gördüm. Buluştuk, çözümü ve sorun üzerinde çalışmanın aşamalarını tartıştık. Açılıştan sonra Kızıl Ekim'e otobüsle gitmek zorunda kalmamıza rağmen, saat 9.00'da oraya varmayı kabul ederek uyumak için eve gittik. Neden? Organizatörler görünüşe göre katılımcılardan en iyi şekilde yararlanmak istiyorlardı ve bu yüzden böyle bir program ayarladılar. Ancak tecrübelerime göre bir gece uyumadan normal şekilde kod yazabilirsiniz. İkinciye gelince, artık emin değilim. Hackathon bir maratondur; gücünüzü yeterince hesaplamanız ve planlamanız gerekir. Üstelik hazırlıklarımız da vardı.
Bu nedenle uyuduktan sonra saat 9.00'da Dewocracy'nin altıncı katında oturuyorduk. Daha sonra tasarımcımız beklenmedik bir şekilde dizüstü bilgisayarının olmadığını ve evden çalışacağını, telefonla iletişim kuracağımızı duyurdu. Bu bardağı taşıran son damla oldu. Ve böylece takım adını değiştirmesek de dörtten üçe döndük. Yine söylüyorum bu bizim için büyük bir darbe olmadı, eski projedeki tasarımı zaten almıştım. Genel olarak, ilk başta her şey oldukça sorunsuz ve plana göre ilerledi. Organizatörlerin yenilikçi şirketlerinin bir veri kümesini veritabanına yükledik (neo4j kullanmaya karar verdik). Dizgi yapmaya başladım, sonra node.js'ye başladım ve sonra işler ters gitmeye başladı. Daha önce neo4j ile hiç çalışmamıştım ve ilk başta bu veritabanı için çalışan bir sürücü arıyordum, sonra nasıl sorgu yazacağımı buldum ve sonra bu veritabanının sorgulandığında varlıkları döndürdüğünü keşfettiğimde şaşırdım. bir dizi düğüm nesnesi ve bunların kenarları şeklindedir. Onlar. Bir kuruluş ve onun içindeki tüm verileri TIN ile talep ettiğimde, tek bir kuruluş nesnesi yerine bana bu kuruluş ve bunlar arasındaki ilişkiler hakkında verileri içeren uzun bir nesne dizisi döndürüldü. Tüm diziyi tarayan ve tüm nesneleri organizasyonlarına göre tek bir nesneye yapıştıran bir eşleyici yazdım. Ancak savaşta, 8 bin kuruluştan oluşan bir veritabanı talep edildiğinde, yaklaşık 20-30 saniye gibi son derece yavaş bir şekilde gerçekleştirildi. Optimizasyon hakkında düşünmeye başladım... Sonra zamanında durup MongoDB'ye geçtik ve bu işlem yaklaşık 30 dakikamızı aldı. Neo4j'de toplamda yaklaşık 5 saat kaybedildi.
Unutmayın, aşina olmadığınız bir hackathona asla teknolojiyi götürmeyin, sürprizler olabilir. Ancak genel olarak bu başarısızlık dışında her şey planlandığı gibi gitti. Ve zaten 9 Aralık sabahı tamamen çalışan bir uygulamamız vardı. Günün geri kalanında buna ek özellikler eklemeyi planladık. Gelecekte, benim için her şey nispeten sorunsuz gitti, ancak destek verenin, tarayıcılarının arama motorlarında yasaklanmasıyla, istekte bulunurken arama sonuçlarında ilk sıralarda yer alan tüzel kişilik toplayıcılarının spam'iyle ilgili bir sürü sorunu vardı. her bir şirket için. Ama bunu kendisinin anlatması onun için daha iyi. Eklediğim ilk ek özellik tam isme göre arama yapmaktı. VKontakte'nin Genel Müdürü. Birkaç saat sürdü.
Böylece, başvurumuzdaki şirketin sayfasında genel müdürün bir avatarı, VKontakte sayfasına bir bağlantı ve diğer bazı veriler belirdi. Bize zafer kazandırmamış olsa da, pastanın üzerinde güzel bir kiraz vardı. Daha sonra bazı analizler yapmak istedim. Ancak uzun bir seçenek arayışından sonra (kullanıcı arayüzünde birçok nüans vardı), kuruluşların ekonomik faaliyet koduna göre en basit şekilde toplanmasına karar verdim. Zaten akşam, son saatlerde yenilikçi ürünleri sergilemek için bir şablon hazırlıyordum (uygulamamızda Ürün ve Hizmetler bölümünün olması gerekiyordu), ancak arka uç buna hazır değildi. Aynı zamanda, veritabanı hızla şişiyordu, tarayıcılar çalışmaya devam etti, arka sunucu, yenilikçi metinleri yenilikçi olmayanlardan ayırmak için NLP'yi denedi))). Ancak son sunumun zamanı yaklaşıyordu.
7. Sunum. Kendi tecrübelerime dayanarak, sunumdan 3-4 saat önce sunum hazırlamaya geçmeniz gerektiğini söyleyebilirim. Özellikle video içeriyorsa çekimi ve kurgusu oldukça fazla zaman alıyor. Bir video çekmemiz gerekiyordu. Bununla ilgilenen ve ayrıca bir takım diğer organizasyonel sorunları çözen özel bir kişimiz vardı. Bu bakımdan son ana kadar kodlamadan kendimizi alıkoymadık.
8. Satış Konuşması. Sunumların ve finallerin hafta içi ayrı bir günde (Pazartesi) yapılması hoşuma gitmedi. Burada, büyük olasılıkla, organizatörlerin katılımcılardan maksimumu alma politikası devam etti. İşten izin almayı planlamadım, ekibimin geri kalanı izinli olmasına rağmen sadece finallere gelmek istedim. Bununla birlikte, hackathonun duygusal yoğunluğu o kadar yüksekti ki, sabah 8'de ekibimin sohbetine (hackathon ekibi değil, çalışma ekibi) günü kendi masraflarımla geçireceğimi yazdım ve merkeze gittim. sahalar için ofis. Sorunumuzda çok sayıda saf veri bilimcinin olduğu ortaya çıktı ve bu, sorunun çözümüne yönelik yaklaşımı büyük ölçüde etkiledi. Birçoğunun iyi bir DS'si vardı, ancak hiç kimsenin çalışan bir prototipi yoktu, birçoğu tarayıcılarının arama motorlarındaki yasaklarını aşamadı. Çalışan bir prototipe sahip tek ekip bizdik. Ve sorunun nasıl çözüleceğini biliyorduk. Sonunda pisti kazandık, ancak en az rekabetçi görevi seçtiğimiz için çok şanslıydık. Diğer pistlerdeki sahalara baktığımızda orada hiç şansımızın olmadığını anladık. Jüri açısından da çok şanslı olduğumuzu da söylemek istiyorum, kodu titizlikle kontrol ettiler. Ve incelemelere bakılırsa, bu tüm parçalarda olmadı.
9. Son. Kod incelemesi için birkaç kez jüri karşısına çağrıldığımızda, sonunda tüm sorunları çözdüğümüzü düşünerek Burger King'e öğle yemeği yemeye gittik. Orada organizatörler bizi tekrar aradılar, siparişlerimizi hızla toplayıp geri dönmek zorunda kaldık.
Organizatör bize hangi odaya girmemiz gerektiğini gösterdi ve içeri girer girmez kendimizi kazanan takımlar için topluluk önünde bir konuşma antrenmanında bulduk. Sahnede performans sergilemesi gereken adamlar iyi ücretlendirilmişti, herkes gerçek şovmenler gibi ortaya çıktı.
Ve itiraf etmeliyim ki, finalde, diğer pistlerin en güçlü takımları karşısında solgun görünüyorduk; hükümetin müşteri adaylığındaki zafer, haklı olarak, emlak teknolojisi pistindeki takıma verildi. Pistteki zaferimize katkıda bulunan temel faktörlerin şunlar olduğunu düşünüyorum: hızlı bir şekilde prototip oluşturabilmemizi sağlayan hazır bir ham parçanın mevcudiyeti, prototipte "önemli noktaların" varlığı (CEO arayışı) (sosyal ağlarda) ve destekçimizin NLP becerileri de jürinin büyük ilgisini çekti.
Ve sonuç olarak, bizi destekleyen herkese, pistimizin jürisine, Evgeniy Evgrafiev'e (hackathon'da çözdüğümüz problemin yazarı) ve tabii ki hackathon organizatörlerine geleneksel teşekkürlerimizi sunarız. Bu belki de şimdiye kadar katıldığım en büyük ve en havalı hackathondu, adamların gelecekte de bu kadar yüksek standartları korumasını diliyorum!
Kaynak: habr.com