Någon här som sitter med några nya roliga tekniker?
 

Jag har under min relativt korta tid här på forumet inte sett speciellt många som jobbat med några nya roliga tekniker, tekniker som gör livet enklare för oss utvecklare.

Min första tanke var att webbutvecklare i allmänhet kanske är något old-school och där av håller sig till vad dom kan och vet bäst, vilket i många fall är de man en gång började med.
Strax där efter så slog det mig att utvecklarna i min omgivning på te.x forum, irc:er, *screencast-siter och även irl lägger vädligt mycket tid på att testa och utveckla nya tekniker som gör arbete enklare och roligare.

Gruppen som jag framförallt syftar på är rails/ruby-communityt där CSS-ramverk och BDD är vardagsbegrepp.

Listar några tekniker/projekt från Gihubs most watched nedan som jag själv använder plus några övriga.

Jag generaliserar begreppet teknik för att göra det enklare för mig att sammanfatta listan nedan.

• SASS - Översätts till CSS(3)
• HAML - Översätts till HTML(5)
• CoffeeScript - Validerad Javascript-kod
• Backbone.js - Ger strukturering i JavaScript
• Silemiun - Använd webbläsaren för att göra tester.
• Cucumber - Tester på rent engelska (nästan)
• Compass - CSS-ramverk
• CouchDB - Dokument-baserad databas
• Node.js/BeaconPush - Realtids-tekniker
• jQuery Mobile - Webbapplikationer för mobilen
• Raphael.js - SVG, vektorgrafik
• jQuery - På gränsen till att tekniken kan kallas ny med tanke på att de flesta använder den.
• Underscore.js - En samling användbara JavaScrip-metoder.

Dessa hör inte explicit till webbutveckling, där av får dom en liten egen lista.

• Github - Kollaborativ utveckling
• Heroku - Molntjänns för Ruby-applikationer

Så min fråga är; varför har inte just du testat någon ny rolig teknik, eller sitter du med något ännu roligare som jag missat i listan?

*med screencast-siter så tänker jag på Railscasts och Peepcode.

Varför arbetar jag med gammal beprövad teknik:
* Nya tekniker inom webben tenderar att inte kunna köras i alla webbläsare
* Nya tekniker skapar nya problem
* Ramverk tenderar att snabba upp så länge man håller sig till ramarna, måste man gå utanför ramarna blir livet ett helvete
* Ramverk tenderar att slöa ner din svarstid
* etc...

Jag menar verkligen inte att allt nytt är kass, men jag menar att det finns problem som man måste ta på allvar. Tänk kritiskt så hittar du de riktiga pärlorna (jQuery är ett exempel).

Nästan alla tekniker som jag nyss nämnde fungerar i alla webbläsare.
jQuery Mobile och Raphael.js är jag dock lite osäker på.

För att du behöver lära dig något nytt, eller på vilket sätt tänkte du?

Har du något exempel på de där?
Har själv inte varit med om de nämligen.

Med bra cache-tekniker så känns det inte riktigt som att det här är ett särskilt stort problem.

Tar det tid att rendera siten, spara renderingen till cachen.
Tar det tid att läsa från databasen, spara informationen till cachen.

Det är i alla fall så jag har löst de med bara ett par rader kod.

Sedan så känns det lite som att flaskhalsen hos majoriteten av webbutvecklarna idag sitter någon helt annan stans. Okomprimerade JS- och CSS-filer är något som jag ser dagligen, för att bara nämna några fel.

Du har ytterligare problem när det gäller ramverk förutom att de oftast är onödiga bromsklossar. Om du ska hitta andra utvecklare som ska arbeta med ditt projekt så måste du hitta just de som kan de ramverk du använder dig av vilket bara krånglar till saker och ting. Minifiering, optimering av olika slag (cache, memcache, sphinx etc.), effektiva template-system (vet inte om du räknar in dessa i ramverk?) för att separarera kod osv. är betydligt bättre tekniker att arbeta med om man ska skriva resurssnål och effektiv kod för stora, moderna webbtjänster. Nu blev det mer serverside men det är där man sparar mest resurser normalt sett även om undantag finns. Det gäller att tänka praktiskt och inte vara cool och använda det senaste "bara för att". Man kan skriva 100 nya ramverk om man nu tycker det är kul men det finns ingen större poäng med det. För de allra flesta webbplatser så spelar det idag heller ingen som helst roll om de komprimerar sin css och js eller inte.

Kan vara värt att lägga till prototype. Yahoo har för övrigt en hel del värdefulla tips för effektivt kodande som tyvärr hamnar lite i skymundan numera.

Problemet ligger snarare för de flesta i strukturen och inte i bristen på ny teknik. Har man mycket js (oavsett eventuellt ramverk) på en trafiktung sajt så bör man tänka efter när man gör vad exempelvis.

Ett annat stort problem är givetvis den breda användningen av färdigutvecklade system som används på fel sätt och förbrukar mångdubbelt mer resurser än det borde. Det är något mer kunniga webbhotellkunder i synnerhet blir lidande av ganska ofta tyvärr.

Nja.. alltså jag dissade inte dina teknologier, de verkar mycket vettiga och jag använder själv en del av dem. Personligen tycker jag att Compass verkar riktigt spännande. Jag pratade mer i generella ordalag.


>> Ramverk tenderar att snabba upp så länge man håller sig
>> till ramarna, måste man gå utanför ramarna blir livet ett
>> helvete.

> Har du något exempel på de där? Har själv inte varit med
> om de nämligen.

Delar av Spring för Java, Hela ASP.NET för att ta ett par ruggiga exempel.


> Sedan så känns det lite som att flaskhalsen hos majoriteten
> av webbutvecklarna idag sitter någon helt annan stans.
> Okomprimerade JS- och CSS-filer är något som jag ser dagligen,
> för att bara nämna några fel.

Jag håller med om att den delen är otroligt eftersatt, ihop med cache-kontroll av statiskt material samt att man inte gzip:ar HTTP-responsen. MEN jag tror tyvärr att slöa ramverk är ett riktigt stort problem på webben idag. Ett problem i stort är att kunskapen om optimeringar är dålig bland utvecklare idag, min gissning är att det till stor del är konsultvärldens fel. Både för att för många rookies anlitas, men även för att kraven ligger på att producera så många sprint tasks som möjligt på så kort tid som möjligt.

Vill återigen gärna poängtera igen att de teknologier du visar upp i din lista inte har något att göra med denna diskussionen. :-)

Om jag ska generalisera lite så uppfattar jag majoriteten av deltagarna på wn.se som mer drivna av att utveckla sin affär (business), eller sitt företagande, snarare än att utveckla den tekniska biten. Dvs många här drivs av ett företagsintresse snarare än ett tekniskt programmeringsfokus. (Däremot verkar det finnas en rejäl bunt hårdvarukunniga personer.)

Rätta mig om jag har fel.

Då företagandet och företagsidén är i fokus är det oftast mer effektivt att jobba med mainstream-tekniker. Mer information på nätet gör det lättare att göra saker själv och lättare att hitta konsulthjälp och lättare att hitta hostingmiljöer och...

(Mycket av det du nämner ovan är å andra sidan bara javascriptbibliotek och varken jquery eller Selenium är något konstigt eller nytt. Raphael var ett bra tips dock! Det tål att undersökas.)

Det är ju stor skillnad på ramverk och ramverk och projekt och projekt, men i många fall kan ramverk göra koden mer överskådlig även för någon som inte är bekant med ramverket. Man måste ändå bekanta sig med strukturen på koden, och det är långt ifrån alltid utveckling utan ramverk resulterar i mer överskådlig struktur.

Själv utvecklar jag huvudsakligen i Actionscript, och mina senaste bekantskaper är Robotlegs, AS3Signals och Promises:
http://www.robotlegs.org/
https://github.com/robertpenner/as3-signals
http://destroytoday.com/blog/2010/11...-is-a-promise/

En fantastisk kombination som inte alls känns som det ger upphov till några begränsningar men som gör det mycket enkelt att skriva väl strukturerad kod.
Jag vet inte om Dependency Injection och IoC är speciellt relevant för ett dynamiskt språk som JS, men för exempelvis AS3, Java och C# är det verkligen långt ifrån en bromskloss och underlättar verkligen då det gäller att strukturera kod.

Robotlegs tillhandahåller helt enkelt Dependency Injection samt kopplingar för events och kommandon samt ramverkbaserade singeltons. Även om ramverket uppmuntrar en MVCS-struktur ger det full frihet att strukturera koden som du vill, och jag har hittills inte varit med om att det har varit ivägen på något sätt utan finns bara där redo att rycka in för att lösa vanligt förekommande problem.

Då det gäller andra ramverk jag har använt känner jag igen mig till viss del i coredevs och tartareandesires reaktioner, men även om långt ifrån alla ramverk är kan eller bör appliceras på alla projekt så kan de många gånger vara extremt hjälpsamma.

Jag pillar just nu med Nooku Framework som är ett ramverk till Joomla. Kanske låter lite tårta på tårta men grymt är det ;)

Läs mer här:
http://www.nooku.org/

Head.js laddar alla javascript-filer parallelt vilket, enligt dem, kan snabba upp sidan med upp till 400%(beroende på hur mycket JS du har).

Jag har provat det, och visst verkar det gå snabbare.

head.js

Kan även slå ett slag för modernizr, som låter dig använda HTML5-taggar i IE, samt lägger till en massa klasser i html-taggen, som definerar vad ens webbläsare har stöd för.

Modernizr

Hej!

Du verkar ha koll på Ruby. Vet du något forum eller någon som kan programmera för en mänsklig summa? Som ensam företaget med två småungar badar man inte direkt i pengar. Vissa stundenter är ruskigt duktiga.

Tacksam för hjälp

Eri
[email protected]

jag håller helt med dig..
jag tror att många börjar kolla på optimering först när kunden skriker..
Det är väldigt viktigt med optimering bland annat eftersom Google rankar delvis på hur snabb sidan är..

Själv håller mig till Drupal där det redan finns fullt stöd till cache, gzip, merge css och JS osv.. funkar väldigt bra prestandamässigt.

Det stämmer nog.

Läste tråden när den kom men har fram tills nu inte haft tid eller syfte med att sätta mig in i de nya namnen som presenterades, förens nu. På senare tid har jag intresserat mig för att skapa olika typer av diagram och grafer och då kom jag att tänka på Raphael-libbet som jag kommer ihåg härifrån. Helt klart är det imponerande, mycket imponerande! Önskar att man själv kunde skriva något liknande utan problem (eller libs). :)

Sitter just nu och ser på ett par screencasts för node.js på nettuts. Vet dock inte ifall jag orkar börja med det ännu.

Så fort jag får tid hade jag tänkt djupdyka totalt i antingen rails (där jag redan varit och utvecklat ett par webapps i, dock aldrig riktigt totalt fastnat för det), alternativt något trevligt ramverk för PHP.

Men tyvärr är det så (enligt mig) att arbetsmarknaden just nu, iaf här i sverige bara vill ha kostymklädda C#-konsulter.. :(

Vi, och många fler av oss, vill ha php-utvecklare. Men det brors nog på vad man vill jobba med också.

Jag håller på att testa F# som är ett funktionellt språk. Det går att köra allt man kan från vanliga .NET CLI/CLR som att anropa moduler skrivna i andra .NET-språk.

F# distribueras gratis () och kan köras med Mono 2.6/2.8.

se mer ref på http://www.fsharp.net

Får ta och väcka den här tråden igen.

På vilket sätt skulle ett ramverk bromsa utvecklingen?

Alla ramverk jag sitter i är väldokumenterade, testade och utvecklas av ett jätte-community. Vilket är inversen till koden Svensson sitter med.

Om någon ska sätta sig in i en kodbas som jag byggt så hänvisar jag bara till de redan satta rekommendationerna och den befintliga dokumentationen.

Hur gör du?

Nu är jag inte helt 100 på vad du menar, men sitter du i ett modernt ramverk i dag, te.x Rails så består kodbasen av en massa byggklossar. De enda Rails-teamet har gjort (kortfattat) är att skriva all boilerplate-code för dig.

Själv förespråkar iden med att implementera kärnan i projekt, inte vill jag jobba med layouten, skriva SQL-kod eller utfinna hjulet på nytt.

Det är även det här som skiljer "agnarna från vetet".

Det ska, enligt min mening, inte ta någon extra tid att göra något så trivialt som att komprimera sina CSS- och JavaScript-filer. Precis på samma sätt som att det inte ska ta någon extra tid att skriva valideras CSS-, JavaScript- och HTML-kod.

Du får gärna skriva booilerplate-koden manuellt om du vill.
Man bör, om möjligt dock lämna över skitgöran till en dator.

Jag tror att det enklaste sättet för dig att se skillnaden mellan Rails och exempelvis Sinatra är att bygga en enklare applikation.

Jag har svårt att se hur man skulle klara av att hålla en större applikation tillräckligt torr i Sinatra. Visst det går, men ack så jobbigt.

Fel. CoffeeScript, HAML, SASS, för att bara nämna några genererar plattformsoberoende, validerad kod efter alla konstens regler.

Koden som i slutändan körs i produktion är alltså mer körbar än koden som du själv skrivit.

Resonerar du så om allt nytt du måste lära sig?

För .NET kanske, men långt i från när det kommer till Rails eller Django.
Du kan ju även fråga dig om det verkligen är rätt att "gå utanför ramarna". I många fall så är begreppet ekvivalent med fulhack.

Men visst, vill du skriva fulkod om du känner för de. Jag gjorde de själv i ung ålder.

Det är billigt att skala en servrar, det är dyrt att ta betala för utveckling.

Det beror helt på vad det är för typ av företag och verksamhet. Jag håller absolut med dig om att det finns fördelar med ramverk också men det passar inte alla och innebär en reell begränsning när man ska ta in nytt folk vilket förmodligen spelar en större roll för små företag med små resurser. Är du en välkänd och attraktiv arbetsgivare så innebär det inte några direkta svårigheter men det är en helt annan situation för okända småföretagare.

Då är allt precis som det ska vara men jag skulle nog tyvärr vilja säga att en övervägande majoritet av alla projekt saknar en vettig dokumentation. Ramverk med en inbyggd standardisering och dokumentationsfunktionalitet är helt klart användbara. Återigen är det nog så att de flesta mindre verksamheter inte anser sig ha tid till detta eller att de inte tror att det kommer till användning. De flesta inser snart att det är precis tvärtom. Det är ofta bra att på ett tidigt stadium bestämma sig för en standard som ska gälla inom ens verksamhet.

Återigen så har du emellertid ett problem i en liten verksamhet med få utvecklingstimmar där du snabbt vill kunna ta in personer för att fixa småsaker.

Zend är också trevligt att arbeta med, likaså jQuery. Det finns som sagt både fördelar och nackdelar med ramverk och det passar inte alltid.

En kompetent person skriver lättillgänglig kod oavsett om ett ramverk används eller inte. Dokumentationen är oerhört mycket viktigare än huruvida man använder ett ramverk eller inte. Saknas sådan blir det krångligt så snart någon annan person är inblandad.

Återigen varierar det från ett projekt till ett annat. Man får också tänka på det hela ur ett miljöperspektiv. Materiella resurser och energi bör begränsas så långt det är möjligt. Det ligger på allas ansvar. Det finns som sagt var aldrig en lösning som passar i alla situationer.

Ditt inlägg blev lite av en enda lång hyllning till Rails :) Det finns ju ett gäng andra ramverk som är betydligt mer välanvända.

Riskerar alltid att bli en PC vs Mac-diskussion i sådana här frågor. Ramverk kan vara bra. Att koda utan ramverk kan vara bra. Tycker vi lämnar den diskussionen nu och återgår till huvudtemat :)

jQuery Mobile är ett väldigt användbart nytt ramverk av betydligt större vikt än exempelvis Rails även om det givetvis inte fyller samma funktion.

Självklart finns det väldigt stora vinster med att använda ramverk, färdiga bibliotek och annat som hjälper till och snabbar på utvecklingen. Men det börjar ju bli farligt när man slänger in allt som är nytt och hett för tillfället utan att göra väldigt grundlig research innan man väljer vilket ramverk man vill satsa på.
Att bygga in sig i fel framverk kan i många fall innebära att man måste bygga om hela applikationen från början mer eller mindre.

Jag anser nog att man bör välja ett fåtal ramverk som man specialiserar sig och blir riktigt bra på istället för att kunna 10-20 stycken halvbra.

Jag har själv specialiserat mig i framförallt CodeIgniter, jQuery och lite CMS-lösningar.

Jag anser precis tvärt om. En utvecklar som testat ett flertal språk, ramverk, plattformar och tekniker har lättare att producera bra kod.

Jag har själv utvecklat småprojekt (< 10k rader kod) i ett 15-tal språk, 10 utav dem kan jag nog sätta mig in i på ett par timmar. De som tar tid att lära sig är inte språket i sig, eller ramverket i fråga utan tekniker för att ta fram bra kod. Att testa andra språk gör att man får en insyn i hur andra skulle löst diverse problem.

Där håller jag inte med.
Det är väldigt svårt och jobbigt att hålla koll på alla ramverksspecifika klasser, funktioner, helpers m.m. vilket gör att man spenderar mer tid på att läsa dokumentationen än man kodar. Sedan skiljer sig ju "best practice" en del mellan olika ramverk vilket gör att det då är svårt att hålla isär.
Vad syftar du på med tekniker för att ta fram bra kod? Ge gärna ett exempel.

Det som tar tid att lära sig är alla funktioner, både inbyggda och de som får i ramverk, extentions m.m.
Vad gör de? Vilken som är bäst att använda i vilka sammanhang? Är de kompatibla med varandra? osv. (jag gissar att det är det här du menar med att skiva bra kod)
Att kunna skriva bra kod utan att sitta och googla och kolla dokumentation varje gång man ska använda en funktion tar lång tid att lära sig och det är förutsättning för att man ska få bra flyt i programmeringen. Man kommer ju självklart inte ifrån det helt men man bör försöka minimera den tiden.

Givetvis är det bra att kunna flera olika för att kunna välja de som är bäst för det specifika projektet och som utvecklare är det säkert bra för förståelsen att man har bredare kunskaper. Men byter man ut vilka ramverk man jobbar med måste man ju börja om och lära sig på nytt. Även om ett annat ramverk kanske är något bättre för ett specifikt projekt bör man nog i de flesta fall ändå använda det man redan kan så att man kan skiva bra kod snabbare om man inte ser en långsiktig vinst med det.

En expert löser uppgifter inom sitt område bättre än en generalist.

Ställ dokumentationsletandet mot maintainability (vad heter det på svenska?), säkerhet och koduppdelning så är de där extra minuterna från att du söker på "codeigniter form validation" tills att du har hittat precis det du vill veta (http://codeigniter.com/user_guide/li...alidation.html) inte så farliga.

Med ett ramverk i botten förenklar man ju såklart underhåll och vidareutveckling för de som är insatta i ramverket och gör det enklare för de som inte är insatta att hitta dokumentation. Det är såklart jättebra.
Men när man bara slänger in alla ramverk och tekniker man kan hitta så går det snabbt åt andra hållet. Slänger du in 15 olika ramverk och tekniker i ett projekt så ökar komplexiteten i projektet oerhört vilket gör att projektet blir svårare att underhålla och vidareutveckla då du måste ta hänsyn till alla saker som spelar in.
Det är ju svårt att veta exakt vad klassen eller funktionen heter i varje ramverk vilket gör det svårt att hitta det snabbt, och sedan är det ju få ramverk som är så väldokumenterade som just CodeIgniter i ditt exempel.

Det är ju också ganska enkelt att generera PHPDoc-filer till de klasser man själv gör också så att andra enkelt kan ta del av den.

Efterfrågan på javautvecklare verkar också vara enorm.

Problemet med php etc är att det verkar finnas ett lönetak runt 25 000 kr medan java och dotNet kan innebära det dubbla och mer för en duktig och erfaren utvecklare.

Men marknaden skriker efter utvecklare just nu.

Det går att tjäna bra mycket mer än 25k som php utvecklare.

Jösses. Den här tråden var intressant till en början men de sista 2/3 eller däromkring är ju helt meningslösa. Ständigt dessa argumentationer fram och tillbaka som inte direkt har med ämnet att göra, suck. :(

Håller med Daek fullständigt, försöker styra in tråden på rätt spår igen :)

Upptäckte nyligen http://api.jquery.com/jquery.tmpl/ som jag kombinerar med http://knockoutjs.com/ för att bygga upp grymma gränssnitt med.

Till er som jobbar med .net mvc kan jag tipsa om:

http://mvccontrib.codeplex.com/wikipage?title=T4MVC Så slipper man använda "magiska" strängar när man ska skriva ut controllers, actions, routes mm

http://nlog-project.org/ Mycket bra om du vill slänga in loggning till din applikation

http://ninject.org/ Dependency injection ,koppla loss beroenden mellan olika delar i applikationen, låt ninject sköta det åt dig, så blir det enklare att maintaina applikationen i framtiden

Kombinera:
http://blog.wekeroad.com/helpy-stuff...all-it-massive
med
http://blog.stevensanderson.com/2011...lding-package/
Så kan du producera applikationer på löpband. Jobba efter samma active record mönster som tex Ruby on rails ;)

Ska vi göra ett försök att helt och hållet undvika att tala nedlåtande om någon annans val av teknologi, programmeringsspråk osv och enbart fokusera på att tipsa andra om ens egna val av ramverk, språk etc.