Profesjonell webutvikling i 2013

[rockPaperScissors()]

Er poenget ditt at "publisering" generelt er "enkelt", mens "uvikling" er "komplekst"? Usikker på hva pointet ditt er.

 

Nei, det var ikke poenget mitt. De to eksemplene med vg.no og Stack Overflow er to nettsteder med ekstrem trafikkmengde, det er ingenting "enkelt" bak å utvikle løsninger som takler slike ting, og sjeldent kan man planlegge for det. Begge tjenestene har garantert måtte gjort noen kompromisser med henhold til funksjonalitet for å opprettholde en stabil tjeneste. Jeg kom på å tenke på de to eksemplene fordi valg av teknologi virker fornuftige i begge tilfellene og framhever styrker og bruksområder for hver av teknologistackene. Men ikke tolk dette som en bastant kategorisering.

 

Utvikling av store sites krever flinke utviklere og driftpersonell. Når du vet at nedetid betyr tapt anseelse og tapt inntekt er det ingen som "leker programmering" (den går vel litt til Jackal antar jeg).

[quantum]

Apropos VG, fant denne i html-sourcen til vg.no

 

<!--
    $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
    $$$		    .$$$$$$$$$$$$		    $$$,						    .$$$$$$$
    $$$$=		   .$$$$$$$$$$		   .$$$		   $$$$$$$$$$I		  $$$$$$
    $$$$$$		   :$$$$$$$$		   I$$$$		  $$$$$$$$$$$$??????????$$$$$$
    $$$$$$$		   +$$$$$$		   $$$$$$		  $$$$$$$$$$$$$$$$$$$$$$$$$$$$
    $$$$$$$$.		   $$$$		   $$$$$$$		  $$$$$$================$$$$$$
    $$$$$$$$$.		  I$$		   $$$$$$$$		  $$$$$$			    $$$$$$
    $$$$$$$$$$I		  I		  ,$$$$$$$$$		  $$$$$$$$$$$$		  $$$$$$
    $$$$$$$$$$$$				   $$$$$$$$$$$		  $$$$$$$$$$$$		  $$$$$$
    $$$$$$$$$$$$$				 $$$$$$$$$$$$		   $$$$$$$$$$		  .$$$$$$
    $$$$$$$$$$$$$$,			  $$$$$$$$$$$$$$$~						   $$$$$$$$
    $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
    Kunnskapstørst? Vi rekrutterer.
    http://tech.vg.no/jobs
    -->

[rockPaperScissors()]

Snedig annonseplassering. Leser du ofte avisen gjennom html-koden quantum?

[tomsi42]

Snedig annonseplassering. Leser du ofte avisen gjennom html-koden quantum?

Uansett hvor dårlig koden er, så er den vel uansett vesentlig mer interessant enn selve avisen?

[quantum]

Snedig annonseplassering. Leser du ofte avisen gjennom html-koden quantum?

Bare stillingsannonsene :-)

[Gjest Slettet+9871234]

Noen som kjenner Java ME and Java Card Technology

 

Java ME technology was originally created in order to deal with the constraints associated with building applications for small devices. For this purpose Oracle defined the basics for Java ME technology to fit such a limited environment and make it possible to create Java applications running on small devices with limited memory, display and power capacity.

 

Java ME platform is a collection of technologies and specifications that can be combined to construct a complete Java runtime environment specifically to fit the requirements of a particular device or market. This offers a flexibility and co-existence for all the players in the eco-system to seamlessly cooperate to offer the most appealing experience for the end-user.

 

Kilde: http://www.oracle.co...-me-395899.html

 

Kan lastes ned her:

 

http://www.oracle.co...vame/index.html

 

Opera Mini er nevnt på bilde 19 av 26 her:

 

http://www.slideshar...es-presentation

 

Noen som bruker Opera Mini på sine mobile plattformer i disse tider hvor alt dreier seg om iPhone /iPad, iOS / Android, Samsung Galaxy / Windows (Phone) 8?

 

Se hva som skjer hos Google med Databoard:

 

http://think.withgoogle.com/databoard/

 

Artikkel:

 

The Databoard is our response to three big challenges facing the vast majority of research released today.

 

1. Ease of consumption: The databoard introduces a new way of sharing data, with all of the information presented in a simple and beautiful way. Users can explore an entire study or jump straight to the topics or datapoints that they care about. The Databoard is also optimized for all devices so you can comfortably explore the research on your computer, tablet, or smartphone.

 

2. Shareability: Most people, when they find a compelling piece of data, want to share it! Whether its with a colleague, client, or a community on a blog or social network, compelling insights and data are meant to be shared. The databoard is designed for shareability, allowing users to share individual charts and insights or collections of data with anyone through email or social networks.

 

3. A cohesive story: Most research studies set out to answer a specific question, like how people use their smartphones in store, or how a specific type of consumer shops. This means that businesses need to look across multiple pieces of research to craft a comprehensive business or marketing strategy. To address this need, the Databoard allows users to curate a customized infographic out of the charts or data points you find important across multiple Google research studies. Creating an infographic is quick and easy, and you can share the finished product with your friends or colleagues.

 

http://googlemobilea...w-way-to_9.html

 

Presentasjon her:

 

http://www.google.co.../databoard.html

Endret 2. august 2013 av Slettet+9871234

[GeirGrusom]

Nå synes jeg ikke VG eller Stackoverflow er veldig representativt for løsningene en jobber med. Ihvertfall jeg har fortsatt til gode å publisere et forum, eller en nyhetstjeneste i profesjonell sammenheng. Selv om det er en løsning med mye trafikk synes jeg ikke det er akkurat det å ha en løsning med mye trafikk som er vanskelig. En må gjøre kompromisser for å sikre oppetid, eller være mer konservativ med endringer, men ihvertfall for meg som backendutvikler så ligger utfordringene i forretningslogikken. Spesielt kundenes evige behov for merkelige detaljer og rapporter, og uvilje til å bruke publiseringstjenester for å lansere eller oppdatere innhold (vi vil bytte navnet på et abonnoment: bug report) og begrensninger i tredjepartsverktøy, eller tilogmed egne verktøy, som sniker inn cowboy-logikk som er legacy så fort det kommer ut i produksjon.

 

Jeg har et par skrekkeksempler på det siste. For noen år siden jobbet jeg med en kunde som skulle ha en helt ny side og en ny kampanje. Vi skulle få priser og produktnavn fra en tredjepartsleverandør som kunden hadde avtale med. Det viste seg at disse hadde release hver 6. måned, så når kunden ville bytte produktnavn og priser, så kunne de rett og slett ikke oppdatere prisene utenfor releasene de normalt hadde. En kan lure på hva slags løsning det var som ikke kunne oppdatere dette etter behov, men at det ikke var mulig var ihvertfall beskjeden. Kunden måtte jo også selvsagt bytte navn og priser på kampanjen under utviklingstiden. Ikke før eller etter, som er merkelig fordi de kan umulig hatt noen som helst datagrunnlag som begrunnelse. Dermed ble det vårt problem. Vi satt med en opprinnelig spesifikasjon som vi hadde fulgt, men som gjorde at vi ikke ville være istand til å levere løsningen kunden nå ville ha. Det ble løst med et oversettelseslag som bare leste produkter fra tjenesten og byttet navn og priser til det kunden ville ha. Det var ikke vår feil, men det ble vårt problem. Gjett om det ikke ble en hel masse forvirring når Foo249 skulle hete Bar299 og Foo299 skulle hete Bar349. Samme tjenesten hadde opp til 4 sekunder latency forøvrig. De fikk forbedret svartiden vesentlig før tjenesten gikk i produksjon, men jeg synes fortsatt 250 ms latency er langt over det jeg hadde forventet av en slik tjeneste. Vi måtte uansett parallellisere alt av kall til tjenesten, i den grad det var mulig, for å få en fornuftig svartid.

 

Det jeg lurer på er om de faktisk hadde hardkodet datasettet denne tjenesten leverte? Hvordan i helsike er det mulig å lage en tjeneste som leverer data, men det er umulig å oppdatere datasettet ved behov?

 

Min erfaring er at trafikk i seg selv er ikke et problem, eller det er i det minste lett å skalere seg etter. Utfordringen er å kunne legge ut en løsning som fungerer riktig i alle bruksscenarioer, og som er enkel å vedlikeholde i ettertid. Det er faktisk det som er jobben. Det finnes ikke perfekte utviklingsverktøy, eller rammeverkt og tjenester uten merkeligheter eller begrensninger. Det å takle dette på en fornuftig måte og samtidig ikke banne over en lav sko er et aspekt som jeg synes er i stor grad oversett.

[Sokkalf™]

Apropos VG, fant denne i html-sourcen til vg.no

 

 

Hehe, de har stillingsannonser ute i HTTP-headerne også.

[The Jackal]

Er poenget ditt at "publisering" generelt er "enkelt", mens "uvikling" er "komplekst"? Usikker på hva pointet ditt er.

 

Halvfabrikatavdelingen? De fleste utviklere med vettet i behold jobber der, mesteparten av tråden her handler om rammeverk, remember?

 

Hvis hovedformålet til en organisasjon er å drive applikasjonsutvikling blir sjelden publisering av egne nettsider prioritert skyhøyt og løsningen blir følgelig heller ikke veldig komplekst og fancy.

 

De aller fleste utviklere jobber da ikke i halvfabrikatavdelingen. Bare så vi snakker om det samme, så mener jeg halvfabrikat som Sharepoint, EpiServer, MSCRM etc etc. Selv om det ofte må lages plugins osv, så blir dette av heller ymse kodekvalitet nettopp fordi de som gjerne jobber der ikke er utviklere. Det var uansett bare min erfaring i forhold til at det helt klart er en todeling av markedet her.

[siDDis]

Så PHP krigen er i gong igjen.

 

Eg hater PHP som pesten, eg skyr så og si alt som brukar PHP. Det einaste som har kome igjennom nåløyet mitt i det siste er pfSense, og det var bare såvidt.

 

PHP betyr bugs! Forferdeleg kodekvalitet. Utviklarar som fokuserer altfor mykje på å lage "beautiful" kode og design patterns i PHP. Jobbar du med PHP, så må du også ofte rydde opp etter andre sitt vræl.

 

Med Python, Ruby eller "moderne Java", så er fokuset på å levere eit awesome produkt. Koden/arkitekturen/designet er alltid av god nok kvalitet.

 

PHP er eit dynamisk språk som er meir verbose enn Java. Og det seier sitt!

[quantum]

De aller fleste utviklere jobber da ikke i halvfabrikatavdelingen. Bare så vi snakker om det samme, så mener jeg halvfabrikat som Sharepoint, EpiServer, MSCRM etc etc. Selv om det ofte må lages plugins osv, så blir dette av heller ymse kodekvalitet nettopp fordi de som gjerne jobber der ikke er utviklere. Det var uansett bare min erfaring i forhold til at det helt klart er en todeling av markedet her.

Det er slik i en del organisasjoner og fenomenet er ikke hardt bundet til utvikling vs. publisering. Det er heller sånn at man svir av kruttet på det som er primærdelen/primærproduktet i virksomheten og så blir resten, f.eks. backoffice-utvikling/vedlikehold, som gjerne kan være publisering, eller like gjerne vedlikehold på salgssystem osv., utført med venstrehånda, enten det er av billigere ressurser eller i brøkdelen av arbeidstiden til champion-utviklerne. Eller ikke - noen steder er det herr Adm. Dir som lager bugtrackingsystem og holder styr på nettsidene mens utviklingsavdelingen utvikler, neppe den billigste måten å gjøre det på :o)

 

Du mener "publiseringsavdelingen" når du sier "halvfabrikat-avdelingen". Pointet mitt var bare at vi bruker en masse ferdige byggeklosser og rammeverk i utviklingsavdelingen også, hovedtyngden av oss som kaller oss utviklere lever et godt stykke oppe i næringskjeden.

Endret 2. august 2013 av quantum

[quantum]

Så PHP krigen er i gong igjen.

Den starta visst akkurat nå, lykke til :o)

[quantum]

 

Det jeg lurer på er om de faktisk hadde hardkodet datasettet denne tjenesten leverte? Hvordan i helsike er det mulig å lage en tjeneste som leverer data, men det er umulig å oppdatere datasettet ved behov?

 

Min erfaring er at trafikk i seg selv er ikke et problem, eller det er i det minste lett å skalere seg etter. Utfordringen er å kunne legge ut en løsning som fungerer riktig i alle bruksscenarioer, og som er enkel å vedlikeholde i ettertid. Det er faktisk det som er jobben. Det finnes ikke perfekte utviklingsverktøy, eller rammeverkt og tjenester uten merkeligheter eller begrensninger. Det å takle dette på en fornuftig måte og samtidig ikke banne over en lav sko er et aspekt som jeg synes er i stor grad oversett.

 

Til det første - godt gjort å hardkode datasettet og fortsatt ha crappy svartider, men alt er jo mulig...

 

Trafikk i seg selv kan være et problem når det er transaksjoner inne i bildet, eller samtidig tilgang til ymse begrensede ressurser, når man er integrert med legacy-systemer som ikke takler trafikk, når databasen blir en flaskehals og så videre. Hvis man er så heldig å få lage et system som ikke skal integreres med noe som helst trenger trafikk som regel ikke være noe issue.

[Gjest Slettet+9871234]

Jeg synes følgende avsnitt er så glimrende at jeg gjengir det her:

 

The game has changed

There was a time, not so long ago, when developers could make a product and people would use it no matter how bad it was. It would generally garner some level of success simply by virtue of its existence. We now live in an age where there is a lot more competition. Now, with tools like jQuery Mobile, anyone can quickly craft impressive-looking mobile sites in a matter of hours.

 

So, how do we differentiate ourselves from the competition? We could certainly compete on price. People love a good value. But there is something that has always seemed to trump price and that is the user's experience. User experience (UX) is what differentiates most of the world's most successful brands.

 

It's hard! We like to think that how we make a program or web page is crucial. We like to think that, by shaving off 10 percent of our code, we're making a big difference. But have you ever tried to explain the details of your current project to a friend and just watched their eyes glaze over? Nobody cares but us. All they hear is faster, smaller, easier, simpler, and so on. They only care about things that directly bear on their life, their user experience.

 

The most important lesson we can learn as developers is that we can write the mos elegant code, create the most efficient systems, accomplish small miracles in less than 1K of JavaScript, but if we fail in the area of usability… we will fail completely.

 

Kilde: http://www.packtpub....ith-jquery/book side 9, 10.

Endret 2. august 2013 av Slettet+9871234

[GeirGrusom]

Trafikk i seg selv kan være et problem når det er transaksjoner inne i bildet, eller samtidig tilgang til ymse begrensede ressurser, når man er integrert med legacy-systemer som ikke takler trafikk, når databasen blir en flaskehals og så videre. Hvis man er så heldig å få lage et system som ikke skal integreres med noe som helst trenger trafikk som regel ikke være noe issue.

 

Jo, det kommer selvsagt an på hva det er man skal løse. Når jeg tenker etter så var jeg i fjor på et prosjekt som konsulent hvor de hadde temmelig alvorlige problemer med databaselåsing. Så jeg trekker det tilbake.

 

Jeg har så mye fantastiske historier fra det stedet der, men de egner seg ikke på et offentlig forum.

[Dundas]

Jeg har så mye fantastiske historier fra det stedet der, men de egner seg ikke på et offentlig forum.

 

Hva med å sende dem inn til http://thedailywtf.com/ ?

[GeirGrusom]

Hva med å sende dem inn til http://thedailywtf.com/ ?

Jeg har vurdert det hardt. Det var svært mye der som egnet seg til det.

 

Kan ta en enkel sak som heter NullParameters.

public class NullParameters
{
 public static string NullString()
 {
return null;
 }
 public static bool NullBool()
 {
return false;
 }
 public static Guid NullGuid()
 {
return new Guid("FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF");
 }
 public static HashMap NullHashMap()
 {
return new HashMap();
 }
 public static int Nullint()
 {
   return int.MaxValue;
 }
}

 

Dette er favorittene mine i denne klassen, men det er masse mer.

Endret 2. august 2013 av GeirGrusom

[Sokkalf™]

WTF!

[Dundas]

Kan ta en enkel sak som heter NullParameters.

public class NullParameters
{
 public static string NullString()
 {
return null;
 }
 public static bool NullBool()
 {
return false;
 }
 public static Guid NullGuid()
 {
return new Guid("FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF");
 }
 public static HashMap NullHashMap()
 {
return new HashMap();
 }
 public static int Nullint()
 {
return int.MaxValue;
 }
}

 

Fnis! Den bør du sende inn.

[Gjest Slettet+9871234]

WTF

 

Det er da ikke et entydig begrep http://en.wikipedia.org/wiki/WTF i disse internet slang tider http://www.internetslang.com/

 

https://en.wikipedia.../Internet_slang

Endret 2. august 2013 av Slettet+9871234