A parte final da triloxía de hackathon. EN Falei sobre a motivación para participar neste tipo de eventos. dedicouse aos erros dos organizadores e aos seus resultados. A parte final responderá preguntas que non encaixan nas dúas primeiras partes.
Cóntanos como comezaches a participar nos hackathons.
Estudiei un máster na Universidade de Lappeenranta mentres resolvía concursos de análise de datos. O meu día típico era así: erguerme ás 8, algunhas parellas na universidade, despois concursos e cursos ata a medianoite (mentres o envío está contando, vexo conferencias ou leo artigos). Un calendario tan estrito deu os seus froitos e gañei o concurso de análise de datos MERC-2017 (do que mesmo se discutiu ). A vitoria deume confianza e, cando accidentalmente atopei información sobre o hackathon SkinHack 2 en Moscova, decidín visitar aos meus pais e ao mesmo tempo descubrir o que é un hackathon.
O hackathon en si resultou bastante divertido. Había dúas pistas sobre análise de datos con métricas claras e un conxunto de datos con premios de 100 rublos. O terceiro tema foi o desenvolvemento de aplicacións cun premio de 50k e non houbo participantes. Nun momento dado, o organizador dixo que unha fiestra cun botón sen funcionalidade podería gañar 50k, porque o premio non se podía pagar. Non comecei a aprender a programar aplicacións (non compito onde se me poida "dar a volta"), pero para min era unha mensaxe clara de que os campos dos hackathons non están ateigados.
Despois resolvín as dúas pistas de análise de datos só. Atopei unha fuga nos datos que me permitiu obter a velocidade ideal, pero a columna coa fuga non estaba nos datos de proba que recibín dúas horas antes do final do evento (por certo, entón entendín que a presenza dunha columna "obxectivo" no tren non conta como unha fuga). Ao mesmo tempo, abriuse a táboa de clasificación, a miña presentación sen cara ocupou o terceiro lugar de cinco, había un gran oco para o primeiro e decidín non perder o tempo e marchei.
Despois de analizar cunha mente fresca o que pasou, atopei unha morea de erros (un dos meus hábitos é percorrer mentalmente o que pasou co bloc de notas e analizar os erros, a súa causa e o que se puido cambiar, un legado tan agradable. dun xogo de póquer semiprofesional). Pero unha cousa estaba clara con certeza: os hackathons teñen moito valor e simplemente tiven que implementalo. Despois deste evento, comecei a supervisar eventos e grupos, e o hackathon posterior non se fixo esperar. Despois outra, e outra...
Por que fas hackathons e non Kaglo?
Non me gusta Kagle polo momento. A partir dun certo nivel de habilidade, sen motivos específicos de participación, o kagle faise menos útil que outras actividades. Antes participei moito, ao parecer conseguín dalgún xeito "baixarme".
Por que hackathons e non traballar no teu propio proxecto?
Gústame a idea de facer algo chulo coas miñas propias mans a un ritmo lento. Os rapaces de ODS organizáronse para todos os que queiran pasar a fin de semana traballando no seu proxecto con persoas afíns. Creo que pronto me unirei a eles.
Como atopas eventos?
Fonte principal: hackathon.com (mundo) e chat de telegram (Rusia). Ademais, os anuncios de eventos aparecen na publicidade nas redes sociais e en linkedin. Se non atopas nada, podes buscar aquí: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Preparas un plan de solución antes de participar ou decídese todo sobre a marcha? Por exemplo, unha semana antes do hackathon, pensas: "Necesitaremos tal especialista aquí, teremos que buscalo"?
Se o hackathon é para comida, si, estou a preparar. Unhas semanas antes, descubro o que vou facer, descubro quen pode ser útil e reúno un equipo de amigos ou participantes de hackathons anteriores.
É realmente posible piratear un hackathon só? Que facer se non hai equipo?
Os hackathons de ciencia de datos son reais (son un exemplo vivo disto), non vin os hackathons de supermercados, aínda que tamén o penso. Desafortunadamente, ás veces os organizadores impoñen un límite ao número mínimo de participantes nun equipo. Creo que isto débese a que non todos os “solitarios” chegan á final (é dicir, simplemente marchan coas primeiras dificultades), a participación nun equipo aínda se limita. Aínda despois do evento, espérase que sigas traballando no proxecto. Será máis doado levar o proxecto a bo porto cun equipo.
En xeral, o meu consello é participar sempre cun equipo. Se non tes o teu propio equipo, os organizadores sempre che axudarán a atopar ou crear un.
Como xestionas a fatiga durante un hackathon?
No hackathon danche 2 días para traballar, é dicir, 48 horas (30-48 horas, tomamos 48 para facilitar a conta). Eliminamos o tempo para durmir (16-20 horas), non deixando máis de 30. Delas, 8 horas (de media) dedicaranse realmente a traballos produtivos. Se organizas correctamente o teu traballo (sono, nutrición, saír ao aire libre, exercicios, minutos de atención plena, comunicación adecuada co equipo e cambio de actividades), entón as horas de traballo profundo poden aumentar a 12-14. Despois de tal traballo sentirase esgotado, pero será unha fatiga agradable. Codificar sen sono e descansos, interrompido por bebidas enerxéticas, é unha receita para o fracaso.
Tes as túas propias canalizacións preparadas para hackathons? Como as conseguiches, como están organizadas (están en cartafoles con ficheiros .py, cada un para a súa tarefa, etc.) e como comezar a crealas ti mesmo?
Non utilizo solucións completamente preparadas de hackathons anteriores noutras novas, pero teño o meu propio zoolóxico de modelos e pipelines de competicións pasadas. Non teño que reescribir pezas estándar desde cero (por exemplo, a codificación de destino correcta ou unha cuadrícula sinxela para extraer a intención do texto), o que me aforra moito tempo.
Polo momento ten o seguinte aspecto: para cada competición ou hackathon hai o seu propio repositorio en GitHub, almacena cadernos, scripts e pequena documentación sobre o que está a suceder. Ademais, hai un repositorio separado para todo tipo de "trucos" en caixa (como a codificación de destino correcta con validación cruzada). Non creo que esta sexa a solución máis elegante, pero de momento me convén.
Comezaría gardando todo o meu código en cartafoles e escribindo unha breve documentación (por que, que, como o fixen e o resultado).
É realista preparar un MVP desde cero en tan pouco tempo ou todos os participantes veñen con solucións preparadas?
Só podo dicir sobre proxectos relacionados coa ciencia de datos: si, é posible. MVP para min é unha combinación de dous factores:
- Unha idea viable presentada como produto (é dicir, pintada nun lenzo empresarial). Sempre debe haber unha comprensión clara de por que e para quen estamos a facer un produto. Ás veces, os proxectos cun deseño ben fundamentado, pero sen prototipo, gañan premios, e isto non é de estrañar. Desafortunadamente, moitos participantes non poden ignorar a amargura da derrota e atribuír os seus fracasos á miope dos organizadores, que seguen cortando modelos para alguén descoñecido nos próximos hackathons.
- Algún indicador de que podes facer este produto (aplicación, código, descrición das canalizacións).
Acontece que un equipo acode a un hackathon cunha solución preparada e intenta "adaptala" ás instrucións dos organizadores. Estes equipos son cortados durante a selección técnica ou só se "conta" a parte que fixeron no sitio. Non vin a eses equipos como gañadores, pero creo que aínda é rendible para eles xogar polo valor futuro ().
Hai algún exemplo de levar artesanía implementada en hackathons á produción/inicio?
Si. Tiven tres casos cando o levaron á produción. Unha vez, dúas veces, coas mans doutra persoa, en función das miñas ideas e do código que escribín no hackathon. Tamén coñezo un par de equipos que seguiron colaborando coa empresa como consultores. Non coñezo os resultados finais, pero o máis probable é que algo se completase. Eu non teño organizado startups e non sei que ninguén o teña, aínda que seguro que hai exemplos.
Despois de participar en moitos hackathons, que consellos te darías se puideses retroceder no tempo?
- As tácticas son máis importantes que as manobras. Pense en cada solución como un produto acabado. Unha idea, un portátil Xúpiter, un algoritmo non valen para nada se non está claro quen pagará por ela.
- Antes de deseñar nada, responde á pregunta non "que?", senón "por que?" E como?". Exemplo: ao deseñar calquera solución de ML, pense primeiro no algoritmo ideal: que recibe como entrada, como se usan as súas predicións no futuro?
- Forma parte dun equipo.
Que alimentan normalmente nos hackathons?
Normalmente a comida nos hackathons é pobre: pizza, bebidas enerxéticas, refrescos. Case sempre a comida organízase en forma de buffet (ou mesa de servizo) ao que hai unha enorme cola. Normalmente non proporcionan comida pola noite, aínda que houbo un caso nunha competición en París onde a comida se deixou durante a noite: patacas fritas, rosquillas e cola. Imaxinarei o proceso de pensamento dos organizadores: “Entón, que comen alí os programadores? Ah, exactamente! Patacas fritas, rosquillas - iso é todo. Imos darlles este lixo". Ao día seguinte preguntei aos organizadores: “Rapaces, é posible facer algo diferente para a noite? Ben, quizais un pouco de mingau? Despois diso miráronme coma se fose un idiota. Famosa hospitalidade francesa.
Nos bos hackathons, a comida pídese en caixas; hai unha división en comidas regulares, vexetarianas e kosher. Ademais poñen unha neveira con iogures e muesli -para os que queiran merendar-. Té, café, auga - estándar. Lembro o hackathon Hack Moscow 2: deronme de bonito borscht e chuletas con puré de patacas na cantina da oficina de 1C.
A cordura dos hackathons depende, por así dicilo, da esfera profesional dos organizadores (por exemplo, os mellores hackathons son realizados por consultores)?
Os mellores hackathons foron de organizadores que xa organizaran hackathons antes ou participaran neles antes. Quizais este sexa o único factor do que depende a calidade do evento.
Como entender que non es un novato e que é hora de un hackathon?
O mellor momento para ir a un hackathon é hai un ano. O segundo mellor momento é agora. Así que vaia, comete erros, aprende, está ben. Incluso unha rede neuronal -o maior invento do home desde que a roda e o gradiente se elevan sobre as árbores- non poden distinguir un gato dun can na primeira época de adestramento.
Que "bandeiras vermellas" indican inmediatamente que o evento non será moi bo e que non hai que perder o tempo?
- Unha descrición clara do que hai que facer (relevante para os hackathons de produtos). Se durante o rexistro recibes unha tarefa clara, é mellor quedarte na casa. Na miña memoria, non houbo nin un bo hackathon con especificacións técnicas. A modo de comparación: vale, fainos algo relacionado coa análise de conversas de audio. Malo: fainos unha aplicación que poida dividir unha conversa en dúas pistas de audio separadas para cada persoa.
- Pequeno fondo de premios. Se che pide que fagas “Tinder para unha tenda en liña con IA” e o premio para o primeiro clasificado é de 500 euros e un equipo mínimo de 5 persoas, probablemente non paga a pena perder o teu tempo (si, este é un auténtico hackathon que foi celebrado en Múnic).
- Falta de datos (relevante para hackatons de ciencia de datos). Os organizadores adoitan proporcionar información básica sobre o evento e ás veces un conxunto de datos de mostra. Se non o proporcionaron, pregunta, non che custará nada. Se dentro de 2-3 non está claro que datos se proporcionarán e se se proporcionarán, esta é unha bandeira vermella.
- Novos organizadores. Non sexas preguiceiro e Google información sobre os organizadores do hackathon. Se celebran un evento deste tipo por primeira vez, hai unha alta probabilidade de que algo saia mal. Por outra banda, se o organizador e os membros do xurado xa realizaron hackathons ou participaron activamente no pasado, esta é unha bandeira verde.
Nunha hackathon dixéronme: “Ti tiveches a mellor solución en pouco tempo, pero perdón, avaliamos o traballo en equipo, e traballaches só. Agora ben, se levas un estudante ou unha rapaza ao teu equipo...”? Encontrácheste algunha vez con tal inxustiza? Como afrontou?
Si, coñecino máis dunha vez. Son estoico con todo o que pasa: fixen todo o que estaba ao meu alcance, se non funcionou, que así sexa.
Por que fas todo isto?
Todo isto é só por aburrimento.
Fonte: www.habr.com