Jeg pønser på at lave en konference om udvikler-værktøjer på Linux/BSD

Ud over at der er gang i at lave DrivingIT konference til november, så har jeg en anden ide til konference som opfølgning til den debuggning-konference, som Kenneth Geisshirt, version2 og jeg lavede i 2013. Jeg vil gerne lave en mini-konference, hvor fokus skal være udvikler-værktøjer og udviklings-flows.
Jeg har nu været i flere firmaer, hvor vi selv udvikler metoder og vælger tools - men der er oplagt, at jeg kan lære af andre, og tilsvarende tror jeg at nogen kan lære af mine valg. Derfor vil jeg gerne mødes med ligesindede udviklere, systemintegratorer og system-ansvarlige.

I mit firma sidder jeg med ca 60-100 fejl, opdateringer eller nyudviklinger per måned og det er vigtigt at vi holder styr på hvad blev lavet hvornår og hvordan ændringer i et modul påvirker systemet. Valg af versions-kontrolsystem, fejlhåndteringssystem, dynamisk og statisk kodeanalyse, systemtest, unit-test, logning, debugmetoder - for et udviklerhold bør de elementer være koblede og designet, så en lang udviklingsproces kan vedligeholdes så det primære fokus ligger på at udvikle.

Mht. konference, så er mine tanker en dag f.eks. i april, og det kan holdes hos et firma, universitet/skole eller lignende. Det behøver ikke være i København, men det er da en kandidat - jeg vil nok skele en del til hvor talerne kommer fra og så vælge sted. Jeg har ikke tænkt på infrastruktur/pris - men kan vi holde det gratis med noget enkel forplejning vil det være fint. Hvis nogen vil sponsorere mad/kaffe så prik lige til mig på .

I må meget gerne hjælpe mig med at afgrænse konferencen ved at debattere nedenfor. Det er vigtigt at konference-talerne har en vis kobling til emner fra de andre talere. Godt nok vil jeg gerne have præsentationer specifik om Jenkins og Git men også gerne om hvordan man binder forskellige dele af udviklingen sammen.

Et par logiske problemer I meget gerne må hjælpe med.

  • Jeg har (nok ikke overraskende) en præference for fri software, og vil meget gerne have talere med det forkus, men kommercielle løsninger som støtter op om udviklingsflows på Linux/BSD/UNIX er også relevante. Jeg er lidt usikker på om det giver mening af tage Windows-udvikingsflows ind? Kommenter gerne nedenfor.
  • Vi udvikler løsninger i forskellige domæner og med forskellige sprog. Nogle er til C/C++ og laver f.eks. low-level kode (som jeg bl.a. gør) - mens andre er til web-applikationer med databaser som oftest anvender Java eller lignende. Skal der skæres i fokus her?

Som I kan se, at ovenstående ikke 100% skåret til. I må meget gerne deltage i hvordan rammer skal skæres. I er også velkomne til at maile mig om det. Men jeg tror det kan blive en super relevant dag sammen med vidensudveksling og diskussion omkring hvordan man
har enten fejlet i eller haft succes med forskellige emner indenfor software-udvikling.

/pto

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Magnus Lund

Ligger det på meningsudvekslinger/inspiration imellem etablerede udviklere - eller på at vise nytilkomne de 10 tips og tricks for at de kommer i gang?

Den sidste del ville jeg som .Net udvikler være meget interesseret i. :-) Jeg har flere gange prøvet at komme i gang med udvikling i Python - men strander ret hurtigt ved tooling - jeg aner slet ikke hvor jeg skal starte og så bliver det lidt fægtning i blinde og en masse frustrationer.

Så måske kunne du overveje et "Newbie" spor? :-)

  • 1
  • 0
Rasmus Olsen

Jeg har flere gange prøvet at komme i gang med udvikling i Python - men strander ret hurtigt ved tooling - jeg aner slet ikke hvor jeg skal starte og så bliver det lidt fægtning i blinde og en masse frustrationer.

Magnus,

Der er et hav af tutorials på nettet, men min erfaring er at der først sker noget når du sætter dig får at løse et eller andet problem relevant for dig. Mit udgangspunkt for at komme igang var et års tid siden hvor jeg skulle binde en PHP app op på et eksternt API. Jeg har tidligere brugt PHP's curl wrapper til den slags, men med Python requests kunne jeg løse opgaven med IMHO langt smukkere og gennemsigtig kode. Herefter gælder det om at finde flere opgaver hvor du kan få sneget Python ind.

Google projektet Pyscripter er til Windows. Simpel, og kan debugge. Jeg sidder på Nix eller OSX, og bruger VIM til små scripts, og Eclipse med PyDev plugin til de større.
Hvad med et Python web framework som Django? Det har givet mig meget.

Vær glad for frustrationer - de gør dig klogere. Intet kommer gratis (især ikke ved selvstudie) ;-)

  • 0
  • 0
Magnus Lund

Problemet for mig ligger ikke i at finde tutorials... det ligger i, at der netop findes 4000 tutorials, som modsiger hinanden og viser 1300 forskellige kombinationer.

For mig ligger problemet i at finde en tilgang, hvor jeg kan se en andens flow - og hvordan valget af værktøjer giver mening. Jeg kan sagtens lave django websites og små hobbyprojekter - men det sker i Idle, og for mig hopper kæden ret hurtigt af, når jeg har mere end 10 filer involveret - derfor frustrationerne.

Selvstudier giver frustrationer og meget ofte grundlæggende fejl i tankegangen - især når man skifter paradigmer. I mit tilfælde både fra statisk -> dynamisk samtidig med Windows -> Linux. Bare at sætte en Linux box op med et IDE, versionsstyring giver mig så mange kombinationsmuligheder, at jeg ikke bliver meget klogere på trods af frustrationer :-).

Jeg mangler nogle fysiske møder med (meget tålmodige) udviklere, som har tid og lyst til at dele deres erfaringer - og hvorfor de er nået frem til deres kombination af værktøjer.

Jeg er bare ikke sikker på, at det er det Peter vil med konferencen :-)

  • 0
  • 0
Rasmus Olsen

Det lyder på mig som om du skal finde en IDE, og tage tingene én ad gangen. Kør Python på Windows, og glem Linux og versionering indtil du er mere dus med sproget? Wikipedias Python artikel har en lang liste med IDE'er. Eclipse med PyDev plugin er fin, og er nem at sætte op til et Python virtuelenv projekt (som du sikkert kører Django i).

Ikke mere off-topic fra mig. God weekend :-)

  • 1
  • 0
Karlo Hansen

Jeg kommer fra en webudvikler baggrund med PHP, så punkterne er måske ikke relevant for alle:
- best-practice ved commits, for bedst muligt brug af loggen
- Branching og tags
- Hvad gør man når tingene eksplodere?(diff, revert og ikke mindst blame)
- Server miljø (Produktion og test site på samme server)
- Gruppe værktøjer som Gitolite og Gitosis
- Den gode gitignore fil/hvordan man holder et repository nede i størrelse

  • 0
  • 0
Jesper Dahl Nyerup

Det lyder brandhyggeligt. Vi (One.com) vil gerne lægge hus til, hvis vi kan finde en dag der lige passer. Vi bor knap 10 minutters gang fra København H, vi har plads til det meste, og så har vi en nydelig udsigt.

Sig i øvrigt lige til, hvis jeg kan hjælpe med noget af det praktiske.

Og så kan jeg heldigvis glæde forsamlingen med, at den-dér $EDITOR-diskussion er dundrende overflødig, thi jeg har fuldendt min konvertering fra Emacs-evangelist til Vim-aficionado. Og det har jeg naturligvis kun gjort, fordi Vim åbenlyst er overlegen.

  • 4
  • 0
Ivo Santos

Konvertering fra windows til linux og omvendt er et af de ting jeg umiddelbart kan tænke på. For enhver som har prøvet at kompiler C/C++ kode vil vide hvor frustrerende det kan være hvis man ikke lige har tænkt over den forskel der er på et 32 bit system og på et 64 bit system, og ikke forstå hvorfor koden ikke vil kompilere.

  • 0
  • 0
Ivan Skytte Jørgensen

I betragtning af at debuggingkonferencen var rigelig presset og kunne have varet længere tid, og at debugging/debuggers kun er en af mange udviklingsværktøjer, så tror jeg at det er nødvendigt at tilskære konference så der er fokus på blot 2 eller 3 områder. F.eks:
* Editors/IDEs (emacs, eclipse, nedit, vi, netbeans, ultraedit, ed!)
* Versionsstyring & merge-værktøjer
* Compilers (der findes andet end gcc og oracle-javac)
* Build, packaging & deployment.
* Test miljøer (VM, remote boxes, linux containers, ...)
* Samarbejdsværktøjer (slack, jira, irc, ...)
* Bugtracking & featuretracking

Og så skal man ikke glemme at der sidder ret mange folk som laver embedded linux, med de dertil hørende udfordringer.

Form:
Ved debugging-konferencen var det ret klart at 25-30 minutter pr. indlæg var for presset. Jeg vil klart foretrække 40-45 minutter og så flere spor.

  • 0
  • 0
Klaus Kolle

Jeg synes forslagene om at fokusere på nogle enkelte område, men så belyse dem fra forskellige vinkler lyder godt. Gerne med rimelig tale- og Q&A-tid til den enkelte foredragsholder.

Ivan Skytte Jørgensens liste rummer mange gode forslag, som sikkert kan udfylde en dag.

Jeg vil også gerne foreslå at konferencen afholdes på Ingeniørhøjskolen, Aarhus Universitet på Katrinebjerg eller på havnen i Navitas - forhåbentlig i samarbejde med en eller flere lokale virksomheder. IDA Embedded trækker også gerne lidt på hamlen med lidt praktik evt. et indlæg eller to.

  • 0
  • 0
Peter Makholm

Jeg tror ikke man skal lægge for meget fokus i at rette konferencen mod en bestemt udviklerprofil. Jeg vil meget gerne høre om hvordan man løser problemerne i andre miljøer end lige mit eget. Det giver mig ny inspiration frem for bare at blive bestyrket i min eksisterende holdning til hvordan man er udvikler.

Men for en del af programmet bør man sørge for gode talere og sørge for at man aftaler nogle forventninger med talerne om at både begyndere og erfarne skal tilgodeses og at der skal være en fokus på processen frem for produktet.

Jeg stiller som sædvanligt gerne op, for eksempel med et nyt afsnit i "Don't try this at home"-sagaen for at dække hvordan man som udvikler kan få glæde af virtualisering.

  • 1
  • 0
Ivan Skytte Jørgensen

Specifikt for editors, så kunne det være interessant at se hvilke tricks folk bruger, som ikke er åbenlyse (specielt for nybegyndere).

F.eks. har jeg stor glæde af at kunne markere en sektion tekst og kører den igennem en ekstern kommando (grep/awk/cut/selv-lavet-script), men jeg tror ikke at sådanne muligheder er åbenlyse for nybegyndere.

  • 0
  • 0
Peter Makholm

Specifikt for editors, så kunne det være interessant at se hvilke tricks folk bruger, som ikke er åbenlyse (specielt for nybegyndere).

Det er også et emne hvor det kan være møgbesværligt at holde et godt foredrag. På den ene side så skriger emnet på at være en live-demo og på den anden side er det meget svært at ramme en balance mellem at folk kan se hvad der foregår (er det relevant at oplægsholderen flytter musen rundt eller skal den bare af vejen) eller at folk falder i søvn af en langvarig tastetryk for tastetryk gennemgang… (for slet ikke at tale om at live-demoer altid er et modigt valg for oplægsholder).

Så et lilel nødråb til ham der eventuelt skal holde oplæg om smarte features i IDE'er så fokuser på en enkelt process ad gange og slå alt andet eye candy fra imens. Hvis processen er refaktorisering af kode, så er automatiske kode-templates, popup hjælpetekster og en debugger-pane generende eye-candy. Slå det fra og lad os nøjes med at se på en skrabet editor og hvad der er nødvendigt for selve refaktoriseringen.

Og så vælg nogle simple kodeeksempler, men giv lige tilhørerne tid til at forstå strukturen. Sørg helst for at det er så simpelt at det er let at overskue selvom man ikke kender til det aktuelle sprog og forklar hurtigt koden.

  • 0
  • 0
Tine Andersen

Kald den Sublimix! (eller er det kun reference for os, der er vokset op med Asterix? Og A. And?) Med ret til at bære: Snesevis underlige bægre lagerøl med intensive xylofoner (AAAV den var rædsomt dårlig!!)

Mvh
Tine- sublim unix mix ;-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere