Flytte Gjennomsnittet Good Eller Bad

Hei, I8217m Leo. Jeg er en hybrid programvareutvikler, designer, markedsfører og gründer. Jeg er administrerende direktør i Ballistiq. et webdesign og utviklingsselskap. Litt mer om meg gtgt Ballistiq Webutvikling Leter du etter et pålitelig, nordamerikansk basert webutviklings team som har en god track record Ballistiq tilbyr skreddersydde design og utviklingstjenester. Weve bygget nettsteder og applikasjoner for topp selskaper, inkludert Autodesk, NVIDIA, Gnomon School of Visual Effects, Allegorithmic, Luxion og mer. Kategorier Ruby on Rails vs PHP 8211 Den gode, dårlige Notat 8211 denne artikkelen ble skrevet i 2012. I8217ve lagt til et tillegg for å oppdatere artikkelen med siste tanker 30. mai 2014 nederst. I8217ve har utviklet seg med PHP siden versjon 2 (veldig lenge siden). Jeg hadde lyst til å komme inn i Ruby on Rails og hadde spilt med den siden versjon 1, men hadde aldri muligheten til å bruke den i produksjon alvorlig til dette året med Ballistiq. Siden da har I8217m nå kodet 8020 Ruby on Rails og PHP, så I8217ll gir mine tanker på de to. På skrivningstidspunktet er versjoner som I8217ll snakker om, PHP 5.3PHP 5.4 og Ruby on Rails 3.2 (kjører på Ruby 1.9.3). Konteksten til dette innlegget er å sammenligne de to spesielt for webutvikling. Aren8217en sammenligner du epler med appelsiner Rails er et rammeverk for Ruby. PHP er et språk og har mange rammer. Hva jeg hovedsakelig sammenligner er mine erfaringer som jobber med begge økosystemer: PHP-rammeverk (det er mange) vs Ruby Rails (det overordnede rammebetinget). Mens noen kan bli hengt opp over å prøve å sammenligne de to, og kan stryke på tittelen på artikkelen, er dette et legitimt spørsmål som mange utviklere spør. Mange utviklere ønsker å vite hva som er fordelene i begge økosystemene og egentlig bare vil ha et klart svar. Fra populariteten til artikkelen via Google, er det noe som titusener av mennesker faktisk spør. Isn8217 er det bare en preferanse Ja og nei. Både PHP og Ruby økosystemet er veldig kraftig. I mange tilfeller, ja du kan bare koker det til en preferanse. Det er imidlertid mange styrker for begge, og it8217s er nyttige for å kunne sammenligne dem på en jevn måte. I8217m ikke religiøst knyttet til en eller annen. I8217ve brukt begge deler. Mitt firma jobber med begge deler. Begge er her for å bli og spille viktige roller i den globale webutviklingsbransjen. PHP 8211 Den gode enkelheten og lærekurven Det jeg absolutt elsker om PHP er dens enkelhet og relativt grunne lærekurve. Når du først kommer inn i PHP, trenger du bare en enkelt HTML-nettside. Endre utvidelsen til. php. Kast i noen ltphp-kode her gt inline PHP, kjør det på en PHP-webserver og utenom deg. It8217s virkelig død enkel for noen helt frisk å få noe nyttig gjort og distribuert innen få minutter. Dette har vært en av styrkene til PHP, og hvorfor det er så populært at 8212 designere og ikke-kodere kan være produktive med en gang. Denne enkelheten kommer imidlertid til en pris. Det er et dobbeltkantet sverd, da det fører til mye slurvet, uoppnåelig kode. Dette fører folk til å bruke rammer som tvinger en bestemt kodingsstandard. Fordelen med PHP8217s enkelhet og grunne lærekurve er en veldig stor ting å gå for det, og dette har også forretningsmessige fordeler: it8217s lettere å finne folk som kjenner PHP. Hvis du ser deg rundt, er Ruby on Rails-utviklere dyrere og vanskeligere å finne. De gode utviklerne som virkelig kjenner Ruby and Rails (L33T) har en tendens til å være mer hardcore devs. Dokumentasjonen for PHP er også fantastisk. Jeg finner docs for PHP langt mer nyttig enn de for Ruby og Rails Guides. Brukeren kommenterer virkelig hjelp, og det er mye eksempelkode som viser hvordan du løser vanlige problemer. It8217s Made For The Web En stor ting om PHP er at den virkelig er fokusert helt for nettet. It8217 er ikke et generelt programmeringsspråk som Ruby (eller PythonJavaCPerletc.). Mange av de innebygde funksjonene er spesifikke for å løse webproblemer, og dette gjør det til et veldig greit språk for å programmere på nettet. F. eks Hvis du vil sende en header til nettleseren, bruker du bare header () - funksjonen. En MD5 eller SHA1 hash er bare md5 () og sha1 (). It8217 er ikke like greit å gjøre dette med RubyRails som du må laste inn i biblioteker og bruke namespacesmodules for å komme til de samme funksjonene. Lot8217s of Resources PHP har massevis av ressurser, rammer, programmer og biblioteker tilgjengelig for det. Fra CMS8217 som WordPress og Drupal til rammer som Symfony og biblioteker som Doctrine, har PHP virkelig mange gode ressurser. Når det gjelder distribusjon av et enkelt CMS, for eksempel, pleier jeg nesten alltid å bare bruke WordPress i stedet for å bygge en Rails-app for det. Jeg føler bare at it8217 er en mye enklere løsning. Død Enkel å Deploy Implementere PHP er død enkel. På sitt enkleste må du bare FTP filene til en webserver (som vi på Ballistiq aldri gjør 8211 vi distribuerer ved hjelp av Git). Thing er, med PHP du trenger ikke å vite om eller bryr seg nødvendigvis om webstakken. Mange hosting-tjenester bruker bare et LAMP-miljø (Linux, Apache, MySQL, PHP), så lenge filene dine er på plass, kjører de bare og that8217s det. Selv ved hjelp av et rammeverk som CodeIgniter er det relativt enkelt som du aldri trenger å bruke kommandolinjen 8212, du kopierer bare hele rammekatalogen til serveren og kjører. Det er det. PHP 8211 Den dårlige utviklingen ledet til mye dårlig kode Dette er ikke en direkte funksjon feil i PHP, men er resultatet av år og år å bygge på toppen av et enkelt skriptspråk som var spesifikk for å løse enkle webproblemer. PHP var ikke alltid Objektorientert. Selv når det sto for OOP, var det i årevis ikke OOP (mangler viktige funksjoner som statiske metoder), så programmører fikk problemer gjennom alle typer shenanigans som å bruke globale variabler eller sette en lokal variabel ved hjelp av en global referansepeker. F. eks Typisk pre-PHP5 kode Dette er bare et par eksempler, men det er mer som jeg vant8217t gå inn her. It8217 er uheldig, men er bare en av bivirkningene ved å jobbe med et språk som har utviklet seg raskt. En ting som driver oss gal på Ballistiq, går inn i prosjekter der vi må oppgradere eller vedlikeholde programmer skrevet med gammel PHP. Dette er tilfellet med et av våre største prosjekter der vi prøver å oppgradere en stor app skrevet i PHP4-kode, og det er forferdelig. Mye slurkaktig kode der vi må jobbe med. Bedre kodestandarder fører til virkelig Purist Code Som nevnt ovenfor er slurvet kode ikke en inneboende funksjon feil i PHP. Det er bare hvordan folk har brukt språket. Siden PHP har blitt mer populært, har it8217s fått stor innflytelse fra bedriftsutviklere som tar en virkelig puristisk tilnærming til programmering. Når du går til konferanser og lytter til disse PHP-eksperter som snakker om beste praksis, blir PHP ikke lenger morsomt å programmere. You8217 ser nesten på et Java-program. Klasser utpeker eksplisitt navneområder, importerer navneområder, eksplisitte getter og setter metoder, eksplisitt erklæring om publicprivate metoder, etc. Koden blir ekstremt verbose. Nå Hvis du vil se et rammeverk som tar en mer puristisk tilnærming til ting, sjekk ut Symfony. It8217 er et flott PHP-rammeverk that8217s klar for bedriftsnivåbruk, men fra et utviklingssynspunkt finner jeg det kjedelig. Ruby on Rails 8211 Den gode modne rammen Jo mer jeg utvikler på Rails, jo mer setter jeg meg pris på og elsker det. I8217ve har funnet at det gjør oss i stand til å skape høyere kvalitetsprodukter for kunder mye raskere, som er mer vedlikeholdsdyktig. It8217 er et modent og stabilt rammeverk som mange store selskaper er komfortable med å introdusere i sine omgivelser. Sammenligne dette med PHP-økosystemet som har mange rammer 8212 there8217s en risiko for å velge et rammeverk og finne ut at it8217s bare ikke så bra støttes flere år fra nå (vi gjorde denne feilen). Hastighet og utvikling Glede Jeg elsker absolutt å jobbe med Rails fordi det som en utviklingsplattform er ekstremt automatisert. Så mange menialoppgaver har blitt automatisert slik at du bare fokuserer helt på å løse forretningsproblemet i stedet for å hack deg rundt et rammeverk. Noen ting som virkelig går for Rails i denne forbindelse er: GeneratorsScaffolding 8211 Gir et veldig godt utgangspunkt for å utvikle seg rundt. Noen PHP-rammer legger nå stillasfunksjoner. GemsPlugins 8211 The Rails samfunnet gir et vell av plugins som Ruby Gems som du bare legger til i prosjektet Gemfile og installere. Dette påskynder utviklings - og vedlikeholdstiden betydelig som du ikke prøver å integrere ulike biblioteker, det er allerede gjort for deg. Active Record ORM 8211 Av alle ORM8217ene jeg har brukt (for PHP I8217ve brukt DataMapper DMZ, FuelKohana, Doctrine), er ActiveRecord i Ruby on Rails ganske enkelt det beste. Det fungerer faktisk og er bemerkelsesverdig grei å bruke. Integrerte testverktøy 8211 Jeg elsker det som ut av porten, Rails har et testramme som kan brukes. I PHP har mange rammer nylig bare forsøkt å integrere PHPUnit, til varierende grad av suksess. Som et programmeringsspråk er Ruby virkelig et utrolig språk. I motsetning til PHP er det egentlig objektorientert fra grunnen opp. Koden er veldig kortfattet og kraftig. Gems (extensions) gjør at du kan slå på nødvendig funksjonalitet. Etter koding i Ruby finner jeg koding i PHP (eller noe annet egentlig) ganske kjedelig. Ruby on Rails 8211 Den Bad Steep Learning Curve Min hovedbiff med Ruby on Rails er at den faktisk har en bratt læringskurve. Ikke tro sprøyten som sier at det er veldig enkelt. De vil vise deg podcaster hvor du bygger et enkelt bloggprogram ved hjelp av stillas og voila Instant nettside. Ingenting kunne være lenger fra sannheten. Rails ser ut til å være enkle fordi de har automatisert mange ting i rammen 8212 dette gjør det ikke lett å forstå. Å utvikle en Rails-app og distribuere det krever faktisk at du kjenner hele stakken. Med PHP kan du bare koble sammen noen inline PHP-koden, FTP den til en server og utenom deg. I Rails trenger du virkelig å vite hva du gjør fra webserveren (Apache eller NginX), sette opp Phusion Passenger og databasemotoren. Da må du håndtere prosesspipeline-prosessen for å forberede appen din til å kjøre i produksjonsmodus. It8217 er ikke så enkelt som å kjøre den i produksjonsmodus 8212, du må forhåndsfortegne dine eiendeler og sørge for at filer faktisk er der. Hvis de ikke er, vil Rails ganske enkelt blåse opp, og du må finne ut hvorfor ved å få tilgang til Rails loggene. Sammenlignet med PHP er Rails også uvennlig når det gjelder feil. Med PHP vil det spytte ut feil på deg i utviklingen og feilmeldingene faktisk gir mening. Vanligvis vil en side gjengis, men delen med feilen vil vise deg hvilken linje feilen oppstod og meldingen er nyttig. I Rails, vanligvis hele appen blåser opp. En siste ting å kaste inn er at gode Ruby on Rails-utviklere pleier å være polyglotter. De kan plukke opp og lære mange språk. Mens nybegynnere kjemper for å bare lære Ruby, bruker Rails folk CoffeeScript i stedet for Javascript, SCSS (eller mindre), og Slim eller HAML. For en nykommer til Rails, deler en del av den bratte kurven ikke bare Ruby og Rails-rammen, men alle disse andre språkene også, Ruby er ikke et lett språk. I8217m beklager å fornærme noen mennesker her, men Ruby er rett og slett ikke så grei som PHP å lære. Det er av all hensikt et ekstremt kraftig språk. Jeg velger å bruke Ruby bare fordi jeg som utvikler mener det er et mye bedre språk enn PHP. Men fra et læringsperspektiv er det ikke. Ruby har mange funksjoner som er rett og slett ikke grei for en nybegynner programmerer å forstå. Et slikt konsept er blokker, procs og lambdas, som Rails bruker tungt. Den klassiske Ruby on Rails-eksemplet jeg vil bruke, er å skape et skjema: Hvis du er ny på Ruby, kan du bli tilgitt for å si, 8220Wait a minute8230.what8217s f8221 Ja sir. Velkommen til blokker. Here8217 er litt ekstremt eksempel: Selv som en erfaren programmerer, gikk jeg crosseyed når jeg så på koden ovenfor. It8217s veldig enkelt faktisk 8211 genererer en 8-tegns tilfeldig streng. Et annet område er metaprogrammering. Here8217s et eksempel: I8217ve lærte Ruby on Rails til erfarne utviklere, og dette reiser dem alltid opp. Hva er egentlig hasone. hasmany og hasandbelongstomany. Det ser ut til at det er noen form for reservert søkeord eller deklarasjon, da disse ikke er innkapslet i en metode. Men i Ruby, er ALLE koden utført. Hver linje av kode er utført, så hasone. hasmany og hasandbelongstomany er bare metoder som utføres når klassen er erklært. Endelig er det en annen ting som gjør Ruby utfordrende for nybegynnere, sin løse syntaks. Let8217 ser igjen på koden ovenfor. It8217s er ikke åpenbart (til en nybegynner) som har en: adresse påkaller en metode fordi parentesene mangler fra innkallingen av metoden. I PHP er syntaksen strengere, og dette gjør det enklere for nybegynnere å vite hva som er hva. Som et språk, spesielt hvis du kommer inn fra andre som CJavaPHP, er Ruby utfordrende, og det vil bøye deg. Når du er ferdig, er it8217s fantastisk, og mange som har tatt spranget, liker virkelig å koding med den. Konklusjon Så fra alt dette, hva konkluderer jeg med PHP er et vennligere inngangspunkt i webutvikling enn RubyRails. It8217s enklere, det er flere ressurser tilgjengelig, og du kan få resultater raskt. Til tross for dette, liker jeg personlig å jobbe med Ruby and Rails mer enn PHP. For mange av årsakene I8217ve beskrevet i denne artikkelen, føler jeg bare at Ruby-økosystemet tilbyr et overlegent verktøysett for å utvikle applikasjoner. Jeg respekterer at de dør-harde PHP-fansen vant 8217t på samme måte som 8211 som 8217 er kule. Min mening er dannet fra å jobbe med begge språk og økosystemer grundig i produksjon. Siden jeg flyttet til Rails, følte I8217ve aldri mye av en trang til å flytte tilbake til utvikling med PHP, og alle mine nye prosjekter pleier å være RubyRails. På Ballistiq. vi utvikler seg i begge deler. Hvis et klientprosjekt allerede har eksisterende PHP-kode og vi8217er utvikler for det, trenger å integrere på programnivå, forblir vi i PHP. Hvis en klient trenger et helt nytt program, eller bygger vi vår egen app, bruker Rails. Addendum 8211 30. mai 2014 Wow it8217s har vært en stund siden jeg skrev dette, og det fortsetter å være en svært høyt rangert artikkel på Google, som tiltrekker mye trafikk. Fordi teknologien utvikler seg i et slikt breakneck-tempo, ville jeg oppdatere denne artikkelen med noen nye tanker. PHP har kommet langt siden jeg skrev denne artikkelen Da jeg skrev denne artikkelen, var PHP litt i en overgangsfase, da mange mennesker fortsatt bruker PHP 4 og prøver å overføre til 5. Symfony 2 var ennå ikke utgitt, og Laravel var bare ikke en stor ting. Fra nå av har PHP litt av en renessanse. Her er noen flotte teknologier som virkelig lager PHP-skinne: Laravel 8211 Som et rammeverk ser Laravel veldig bra ut, og mange PHP-folk har valgt det som deres valgramme. Jeg kan snakke for det fordi jeg har brukt det i produksjon. Men det ser bra ut. Komponist 8211 Komponist er til PHP hva RubyGems Bundler er til Ruby. Det gjør pakkeadministrasjon som ikke suger. I årevis måtte PHP-fellesskapet håndtere Pear, som egentlig ikke fikk mye trekkraft. PHP webserver 8211 I lang tid utviklet det med PHP på datamaskinen din at du måtte stole på en ekstern webserver som Apache. Mange devs endte opp med å installere MAMP. Fra PHP 5.4 kommer PHP nå med sin egen kommandolinje webserver, og it8217s er faktisk bemerkelsesverdig lett å skyte opp. Nå fungerer ikke alt med kommandolinjens webserver (jeg hadde problemer med å få WordPress til å starte opp med det), men hvis du utvikler med et rammeverk som støtter dette, er it8217s en mye bedre og renere måte å utvikle. Codeception 8211 En av våre teammedlemmer på Ballistiq ga en veldig fin snakk om et testramme kalt Codeception, og jeg må si at det faktisk ser anstendig ut, som støtter ting som Selen og BDD stiltester. HHVM 8211 Opensource prosjekt ledet av Facebook, dette tar PHP og kompilerer det til bytecode som igjen blir oversatt til x64 maskinkode og kjører veldig fort. Dette er et veldig interessant prosjekt som gjør PHP svært effektiv og skalerbar. Så PHP isn8217t går bort når som helst snart. Mange bruker det og legger det til god bruk. Imidlertid har jeg (og mange webingeniører) flyttet videre. Som ingeniører hakker vi i alt som vi trenger for å få jobben, men etter hvert valgte jeg å starte et nytt prosjekt i PHP. Hvorfor jeg føler at det er flere interessante løsninger der ute som er verdt å se på. Hvorfor elsker jeg fortsatt Rails som rammeverk og Ruby som språk Som jeg nevnte tilbake i 2012, likte jeg virkelig å jobbe med Ruby and Rails. Til tross for den brede læringskurven i 822, traff jeg etter en stund et spor og nå er applikasjonene vi leverer så gode at jeg ikke kan forestille meg å gå tilbake. Her er noen av tingene som går til RubyRails som jeg føler virkelig gjør det så sterkt valg: Gems 8211 Da jeg begynte å kode i Ruby, forvirret Gems meg mer enn de hjalp fordi det var for mye 8216magic8217. Når jeg lærte at du kunne (og burde) bare lese kildekoden for edelstener, gjorde alt så mye mer mening. På grunn av den pluggable naturen av edelstener og community8217s standarder, kan edelstener gi søknaden din en enorm mengde funksjonalitet veldig raskt. Noen edelstener som jeg ikke kan leve uten: Devise (autentisering 8211 håndterer brukerlogg, sosialt tegn på, glem passord arbeidsflyter og så mye mer), Paperclip (filopplastinger 8211 selv håndterer opplasting til S3, bilde croppingresampling), gjør Simple Form danner utrolig enkle å standardisere og gjengi på nettsteder. Mountable Engines 8211 Vi gjorde et mammutprosjekt for et Fortune 500-selskap der etter å ha bygget den første applikasjonen, var det så vellykket at andre avdelinger ønsket samme applikasjon, men med litt annen funksjonalitet og forskjellige brukergrensesnitt. I stedet for å kopiere applikasjonen og måtte støtte flere kodebaser, kunne vi trekke ut det meste av kjernefunksjonaliteten i en Rails-monterbar motor, og har bokstavelig talt en kodebase, men flere nettsteder. Klienten var helt begeistret over dette, og det var en stor seier for oss. Skalering 8211 Rails har et stigma for å være i stand til å skalere og de refererer til Twitter dumping Rails. Vi har ikke funnet noen skaleringsproblemer med Rails, og vi har programmer som kjører med millioner av sidevisninger og hundretusenvis av brukere hver måned. Faktum er at flertallet av dere aldri vil få de skaleringsproblemer som Twitter hadde. Faktisk fant vi det lettere å skalere med Rails enn med PHP. Hvordan først og fremst støtter Rails caching ut av esken. You8217re kan gjøre visningsfragment caching i søknadskoden din og bruke Redis som en cache-butikk. Det er en langt enklere løsning enn å prøve å bruke Varnish som caches alt som går gjennom det, og forlater innloggede brukere uten caching. Ved hjelp av innebygd Rails-caching ble det mulig å skalere på en skala. For det andre gjør Rails Capistrano Chef det veldig enkelt å skalere til flere servermiljøer veldig raskt. Vår typiske Amazon AWS infrastruktur inkluderer Elastic Load Balancer, flere applikasjonsserver forekommer en redissearch server, støttet av en RDS database forekomst. Vi setter opp servering med Chef, slik at vi kan gi en ny, klar til å kjøre forekomst i løpet av få minutter. Samtidig distribusjon komplett med data migreringer kan gjøres med Capistrano fra kommandolinjen. Bokstavelig talt skriver jeg inn cap-produksjonsutplassering: migreringer og alt er magisk distribuert til alle våre applikasjonsservere. Brukere don8217t ser noen nedetid som vi har Phusion Passenger Enterprise og rullende omstart. Bakgrunnsoppgaver 8211 PHP ble designet som en hypertekst-forprosessor, noe som betyr at den bare kjøres når det er en webforespørsel. Sammenlignet med Ruby som driver en prosess. I Rails kan du enkelt sette opp bakgrunnsjobber ved hjelp av Sidekiq eller Resque. Dette legger også til Rails8217 evne til å skalere enkelt. I våre applikasjoner flytter vi mange ting som kan redusere forespørsler som e-postbrukere til bakgrunnsjobber. Nå kan PHP gjøre bakgrunnsjobber ved hjelp av Gearman, men at8217s ikke standardisert 8211 må du installere PECL-utvidelsen. I RubyRails er bakgrunnsoppgaver et ikke-problem. Du gjør det bare. Rails er BORING 8211 Rails er nå på versjon 4.x. It8217 er et modent rammeverk. It8217s kjedelig nå. De kule barna er touting NodeJS disse dager. Rails er kjedelig fordi it8217s robust og stabil. We8217ve utviklet apps i Rails nå for noen av verdens største bedrifter og folk i deres IT-avdelinger don8217t bat et øyelokk. It8217s visste at it8217 er et godt valg å bygge din (robuste, bedriftsklare, skalerbare, ytelsesfulle) applikasjon på. Andre teknologier som jeg synes er å skape Internett AngularJS 8211 Vi introducert AngularJS i våre klientprosjekter tidligere i år for to Fortune 500-selskaper, og det var en stor seier. AngularJS lar deg bygge enkeltsidige applikasjoner som kjører i Javascript. Mesteparten av din front-end logikk går inn i AngularJS, og din backend bare fordi en API som serverer JSON. Dette gjorde vi i stand til å bygge svært effektive applikasjoner. Brukeropplevelsen er veldig bra med denne tilnærmingen fordi sidene lastes ekstremt raskt fordi nettleseren ikke trenger å gjøre en fullstendig rundreiseforespørsel. NodeJS 8211 Jeg begynte å utvikle i NodeJS for noen måneder siden, og det blåste meg. Hva NodeJS er veldig bra for, er å bygge nettverksapplikasjoner. F. eks Hvis du bygger et chatprogram i sanntid, kan du bruke NodeJS for det. På grunn av Rails-moden, tror jeg ikke at vi skal flytte det snart når vi bygger store applikasjoner, men for å legge til sanntids komponenter, vil jeg bruke NodeJS SocketIO. Så hva skal du gjøre Webutvikling blir utrolig komplisert. Dagene til en enkelt utvikler som er i stand til å sende en full søknad fra start til slutt blir vanskeligere. Selv frontend kan ikke lenger håndteres av en enkelt hybrid designerveloper som kan hack CSS HTML markup. Hvis du bare starter, anbefaler jeg fortsatt at du starter med PHP. Du vil få resultater mye raskere, og dette vil øke din vekst og kunnskap. Hoppe inn i RubyRails som ditt morsmål kan gi deg virkelig frustrert forsøk på å få resultater 8211 husk, med Rails, du må kjenne hele stakken så det er ikke bare språket og rammen du utfordrer. Når you8217re er komfortabel med å bygge skreddersydde applikasjoner i PHP, kan du så appetitere og begynne å bruke andre teknologier som RubyRails og selv NodeJSExpress, og you8217ll setter pris på hva disse teknologiene tilbyr. Mange av konseptene du vil lære fra PHP i rammer som Symfony amp Laravel, overfører til andre språk og rammer. En annen grunn til at jeg anbefaler PHP som et godt utgangspunkt er at it8217s er veldig nyttig å vite, slik at du kan hacke på ting som WordPress-temaer og plugins. WordPress er så mye brukt i dag i virksomheten (spesielt markedsføring avdelinger) og it8217s flott å ha programvare polyglots som kan jobbe med mange forskjellige verktøy og plattformer. Det du må innse er at Internett ikke handler om hvilket språk du velger å utvikle med 8212 it8217s om standardene og hva det tar å få informasjon inn og ut av nettleseren. Det spiller ingen rolle hva som er på serveren, så lenge det spytter ut HTML og den rette JSON-data 8211 kan du bruke C til alle som bryr seg. That8217s hvorfor det er så mange webteknologier fra PHP til Ruby til Python til Java og Gosh Perl er fortsatt brukt (jeg møtte en fyr som skrev en Shopify App helt i Perl). Så der går du. Fortsett med hacking Du kan gjøre noe i PHP som du kan i Rails og omvendt. Det er nok for meg å holde fast med PHP. Så langt som Rails blir raskere å distribuere, tviler jeg virkelig på det. Det er ikke mye tid som kan lagres i PHP vs. et annet språk med eksisterende rammer jeg allerede bruker (med mindre selvfølgelig bygger vi AI for å starte programmeringskoden). Fin artikkel. Jeg er helt enig fordi I8217ve hadde den samme opplevelsen som kommer fra en PHP-bakgrunn til RoR. I8217m bare glad i8217m ikke den eneste som synes å lære Rails er vanskelig. Jeg prøver fortsatt å få hodet mitt rundt Coffeescript. Jeg vil gjerne gi noen råd til leserne, en virkelig god måte å lære Ruby and Rails ved å gjøre det GRATIS SaaS-kurset fra Edx (edx. orgcourseuc-berkeleycs-169-1xsoftware-service993). Ikke bare vil du lære Solid Ruby on Rails, men du vil lære gode tekniske aspekter og ende opp med et sertifikat fra Berkeley University også. Annet enn det, kan jeg anbefale Ruby on Rails Tutorial 2ed av Michael Hartl. og Head First Rails (O8217 Reilly). Husk, jo mer du gir RoR en sjanse, jo mer du8217ll elsker det. Flott skrive opp. Jeg er mer en javascript-fyr som noen ganger bruker php for server siden. Siden node kom, begynte å bruke javasript på server siden også. Mange av de kule verktøyene som jeg bruker som Jekyll, Sass og kompass er skrevet i Ruby, så jeg ble alltid fristet til å lære rubin. Jeg har observert mange kolleger som flytter til Ruby eller Python fordi de føler at det å være en php-programmerer bare ikke får samme respekt. Stor, balansert artikkel Leo, takk for at du ikke hypinger den ene eller den andre og gjenværende mål om din erfaring. Distribusjonskompleksiteten til RoR angår meg, mens jeg liker de andre aspektene. Fin artikkel. Jeg er både PHP og Ruby on Rails programmerer. Jeg velger Rails fordi i motsetning til PHP er det for mange å studere avhengig av dine behov. Mye rammeverk og cms. Mens Ruby er skinner, er alt du trenger. du kan gjøre skala apps. Veldig nyttig artikkel, Leo. I8217ve har dyppet tærne i webutvikling de siste seks månedene og har jobbet hovedsakelig med PHP, men Ruby on Rails er neste på min språkliste. Som en erfaren webutvikler, vil du foreslå at jeg fortsetter med PHP og gå videre til Rails etter at jeg får litt erfaring eller hoppe rett inn i Rails Hi Michael. Jeg synes det er verdifullt å vite begge. Definitivt i dagens klima vil kunnskap om Rails få deg en jobb veldig raskt, da det er mer etterspørsel og mindre konkurranse. Hvis du er helt ny for webutvikling, tror jeg PHP er et bedre utgangspunkt fordi du får resultater raskere, noe som vil stimulere deg til å fortsette i webutvikling. Jeg kan nok stresse hvor små suksesser bygger på hverandre. Du kan bygge et godt, tilpasset MVC-program raskt med noe som CakePHP eller CodeIgniter. Når du flytter til Rails, anbefaler I8217d ikke å lære Rails først. Lær Ruby først og prøv å bruke et rammeverk som Sinatra til å begynne med. Min begrunnelse er at Rails har for mye 8220automagic8221 som gjør det svært vanskelig å forstå hva som skjer under hetten. Hvis du ikke forstår hva Rails gjør under hetten, og du ikke vet hvordan du skal se i Rails kildekode og finne ut det, kan feilsøking dine applikasjoner være svært lang og frustrerende, spesielt for en nybegynner. Takk for det nyttige svaret Leo, jeg er helt enig i at det å lære Ruby er super viktig før du hopper inn i Rails. Det er definitivt mye å lære for meg, men I8217m er veldig spent og motivert av hver liten suksess. Cheers Couldn8217t enig mer. Som en nyere Ruby og RoR dev, var det instrumental at jeg lærte Ruby først. Mens RoR er Ruby i kjernen, håndterer den mange av de rudimentære oppgavene for you8230, derfor Rails 8220Magic8221. Hvis du ikke har en anstendig forståelse av hvordan du bruker Ruby uten et webramme, vil what8217s som skjer under hetten absolutt frustrere deg, spesielt når det gjelder feilsøking eller til og med å forstå hva det riktige verktøyet er for jobben. Stor artikkel, Leo Jeg, som de fleste andre, setter pris på en rettferdig og balansert representasjon av begge språk og deres respektive rammer. eller chars (8216a8217..8217z8217).toa Array. new (8).join Første språk jeg noensinne har lært var Turbo Pascal. Så Java. Første webprogrammeringsspråk jeg lærte var PHP. Veldig informativ. I8217m ny til programmering og ser på både PHP og Ruby som server-side språk (I8217ll bestemme hvilken som skal gå med en gang i8217m inn i det litt mer). Jeg er enig i at PHP er lettere å plukke opp 8216 av bat8217, men det er veldig vanskelig å finne gode opplæringsveiledninger eller veiledning der ute. Det er latterlig å se det som lenge siden. På den annen side har Ruby en bratt læringskurve (selv om å lære PHP i tandem synes å ha hjulpet meg med å forstå det), men ressursene for læring som er der ute, er både enklere å finne og en hel haug bedre. Kode skole, for eksempel (sjekk ut om you8217re er ny til utvikling) er en fantastisk resource8230, men doesn8217t til og med berøre PHP. Jeg ser Ruby som fremtidens SS-språk. Jeg jobber med Ruby på skinner. Bruke Ruby på skinner til å bygge rock solid kode, og dermed kvalitets nettsteder som blir enkle å vedlikeholde etterpå. Ruby on Rails er også kjent for sin kodingskonvensjon, agile praksis og sikkerhetsstyrke. Men det er verdifullt å vite både Nice artikkel. I8217ve har kommet inn på web dev med Rails i løpet av de siste månedene, og it8217s hyggelig å se at I8217m ikke er alene i min tro at det ganske enkelt isn8217t er veldig intuitivt. Sammenligningen er faktisk som epler og appelsiner, men det er nyttig når man vurderer hvilket område å fokusere på å studere. I8217m plukker for tiden opp bransjeerfaring med Rails, men er nølende med å forplikte seg til å gå hele milen i dette området fordi kurven er så bratt, og jeg vet ikke om jeg vil være en Rails dev. God artikkel. Jeg føler meg akkurat på samme måte. Etter gt10 år php og Java lærte jeg å like rubin. Og roen i skinnet gir meg et stressende prosjekt. Blindt vite hvor å sette ny kode selv etter 12 timers koding klokka 4 om morgenen. Men jeg hater virkelig kompleksiteten du nevnte angående infrastrukturoppsettet. Noen mennesker liker det 8211 Jeg don8217t. Live er for kort for slike dumme oppgaver. Jeg lurer alltid på hvorfor can8217t RubyRails folkene klarer å lage en oppsettrutine that8217s så enkelt som php Hvorfor må jeg kjempe med Ruby versjon edelversjon mac OSX versjon inkonsekvenser for 2 dager før skinner server vil kjøre første gang Grmpffff8230. Egentlig, du trenger ikke 8220fight with8221 versjoner. 8211 Ruby versjoner: Generelt administrert av rbenvrvm et al. (rbenv er offisielt anbefalt av Rails 8211 rubyonrails. orgdownload). Hvis din innfødte Ruby tilfredsstiller Ruby-versjonen som kreves av prosjektet ved hånden (for eksempel 1.9.3 for Rails 4, 1.8.7 for Rails 3.2), så er du bra, og du trenger ikke verktøyene. But if you are doing client work, or even experiments (e. g. your main project is Rails 3, you are experimenting onplanning on switching to Rails 4) you8217ll need multiple Ruby versions running simultaneously in the same machine. You can use Vagrant et al. but that can8217t beat having it in your base OS. Rbenvrvmetc makes this possible only with a few lines of commands. You can say that one can just use the latest possible Ruby, but it doesn8217t always work like that (compatibility problems etc). Now try that with PHP. There are PHP version switching tools but they were nowhere near maturefull-fledgedeasy-to-use as rbenvrvm last time I checked. 8211 Gem versions: Seriously Show me a single languageframework with a packagedependency manager that doesn8217t involve version numbers (e. g. PHP8217s composer, Python8217s PIP, Closure8217s Leiningen, Java8217s Maven) Ever heard of DLL Hell 8211 Mac OSX: I8217m an Ubuntu user but I8217d be surprised if you can8217t get anything related to RubyRails working in MacOSX, seeing that most Rails developers are using Macs. 8211 You need to to install rbnevrvm on a machine only once. After that, you can install any version of Rubies and Gems in a matter of minutes. And with Heroku, you can see your thing in interwebs in seconds. And you have proven deployment tools like Capistrano which works for any empty Linux box. Yeah, PHP shared hosting is really ubiquitous (in most of which you still can8217t reliablysecurely run modern PHP frameworks), but here the scopes are really different. 8230from a long time PHP user who is busy switching to Laravel 4 and Rails 4 at the same time in production projects for the last 1-2 months. I8217m just finishing up a big L4 project and about to get started with ROR myself. hi leonard I am from India this article is very useful I want some suggestions on building a big eCommerce website. I have a good experience of making website in asp, asp Ajax and sql server 2008. Now I am thinking about moving from Microsoft (because of cost). Please help me choose between php(plain),php with mvc framework, django (not rails because of steep learning curve and updating the website after the host has updated the version).I have no experience on any of the above three. and I will develop alone and I want to cost to be on lower side. Any help would be useful Thanks for this article. As a programmer who8217s been out of the loop for a while (no pun), I had suddenly been preached to about RoR by kids who had never been across other languages. as if RoR was the be all and end all. Your article clarifies all the pros and cons very objectively. Much appreciated. As a would-be programmer starting out and slightly overwhelmed with all the languages and pressure with choosing one: really interesting article. Thanks Thanks for this Article. I8217m using PHP (Laravel framework) for development and Codeception for automate testing. Should I try RoR I8217ve heard that RoR have testing amp deployment tool which help us saving time a lot. Do you have any recommends for me. Thank you in advance We can not compare a programming language with a framework for a programming language. If you don8217t get this then you must start to learn again. A very well considered, helpful and well written article. Thank you Leo. Just read your article. I started my developing 8216career8217 in ASP webforms, which was quite easy and then switch to MVC with scaffolding, razor, nuget, entity framework, jquery, etc. It seems to me that Microsoft8217s stack is well-build and although I found it hard to learn MVC, it all fits together. Maybe they have 8216stolen8217 all good ideas from other frameworks and languages but they combined them very well and build a great IDE. So why does no one use it these days I read a lot of articles about what framework and language is the best, but they never compare it to ASP. Is it 8216just8217 because it8217s Microsoft The best article i8217ve ever read about ruby n php. Thanks for this Meanwhile, in Morocco: Hi. I loved your blog and it helped me a lot. Thank you so much I wanted to ask you one thing My first Rails app is a mobile app that will start with almost 1 million users (from another app my company is buying) and also a web application, like Facebook that you use in the browser and on your iPhone. I don8217t know how many nodes I can start with and I can8217t find a lot of information online. We have one server (16 GB RAM) I am using to test load balancer, database replication I can create as many VPS in the server as it fits in this server. I don8217t know if 16 GB will be enough for 1 million users but I created 6 nodes for staging (and learn): 8211 one with Nginx for load balancing (512MB) 8211 two with Unicorn for the Rails application (1GB each) 8211 two for MySQL (one master, one slave, but I still have to learn how to make Rails read from slave and write in the master, 2GB each) 8211 one for files (512MB shared via NFS with the load balancers and apps, where paperclip will write). The database will have a lot of writes. What architecture configuration you recommend Am I too wrong I used small RAM because I will use more for production but I don8217t know if 6 nodes is enough or if 16 GB will be enough. Can you help me Thank you 1 million users who are logged in, or 1 million users per month who are mostly just browsing the site Also, is the Rails application going to just be for an API or will it actually deliver the pages It also depends on the memory footprint of your application, if it is large or not. 1. 16GB is not likely enough for 1 million users if it is a reasonably sized application, and for that number of users I wouldn8217t put everything on a single server anyway. I8217d load balance across 2x 16GB (or 32GB) servers, quad cores minimum and scale from there. Remember, Ruby applications tend to bloat with lots of gems that you load in. The typical way to scale is to get as much memory as possible and run as many concurrent processes as you can in memory. 2. I would not use Unicorn. It is flaky and consumes a lot of memory. For that kind of scale, I would use Passenger Enterprise. If you want to be cheap and not pay for the Passenger license (which is worth it), you can use Puma. 4. Cache, cache, cache. Have one server just for Redis and cache the hell out of your application: guides. rubyonrails. orgcachingwithrails. html 5. Move slow processes into Sidekiq for background processing. Thank you so much. It is 1 million users registered but usually 20,000 to 300,000 concurrent connections. And it8217s HTML and JSON, depends of the extension. We want to grow, of course, so need to be ready to more. I thought Unicorn was the best. I was using memcached but I will try Redis. Thank you very much again. It was hard to find something online explaining how much memory and how many servers in the load balancer and things like this. Just think about this: if Facebook was done in PHP, which is probably the most robust and used web application in the planet, you don8217t need to be a very smart person to realize php is far from being a bad programming language. in fact, PHP in the next 5 years will become the definitive best web programming language on top of every other one by far. Why Because its syntax is more human readable. The only reason why RoR is so trendy, is because it did very cool stuff a few years ago not available in php. But php is getting better day by day, frameworks like laravest are getting tremendous attention, and even bringing back old php users who are dropping RoR and coming back like prodigal sons. Yes, RoR deserves the credit of pioneering MVC and many other things, but it lacks the beauty and simplicity of C syntax, which will reign forever and ever. There8217s a lot of hype regarding RoR, most people try RoR just because they want to feel trendy and cool, one of the reasons most hipsters use it. Don8217t be a victim of the phenomenon. PHP is not a trendy thing, PHP, without all the noise and propaganda, still dominates the web. Juan David Pasts Rivera Another alternative is Meteor, which is great, is a framework on top of node js, is the one I like the most from all that I have tried: derbyjs, deployd, sails, express, from what I remember. Even when it8217s not comparable with Angular, Meteor supersedes it since you have 2 way data binding and backend logic at the same time and written in JavaScript, also you don8217t have to learn ng attributes. PHP has Facebook as a great representative, but its syntax is not as simple as you can get with Meteor and preprocessing packages. Anyway, scaling is always another whole story, it8217s a huge work which can be done in all languagesframeworks, I am not sure in which of them is easier though. If that8217s so then why does nobody choose to write apps in COBOL or BASIC anymore Why would you choose CoffeeScript over Javascript Why has Apple created Swift when people can just as well use Objective-C Why does it take a non-speaker on average twice as long to learn Russian compared to Italian To say it8217s all about preferences and claim that somehow all languages are equal is pretty naive. I like Php spent a lot of time learning it built most projects in Php and will continue doing so. The only reason I8217m learning ROR now is because I get tons of job offers some remote. I look at it this way freelance jobs I8217m using Php. Contract long term company jobs ROR I guess. I8217m currently in between angularjs now because at my company we wanted to try this out with Ruby as the backend. So imagine the steep learning curve I8217m going through for both of these languages Ruby and AngularJS at the same time. Yet another moving average crossover system Oh, but this one is so much fun This is a trend trading system using very clean charts. Which time frame (TF) Any two TFs with a ratio of 1:4 - 1:6 . for example: I use the H1 and the M15 TFs with a ratio of 1:4. But you could use the H4 and H1 charts (ratio 1:4) or the daily and the H4 charts (ratio 1:6). you get the picture. Any, but I will only use GBPUSD, EURUSD or AUDUSD for illustrative purposes. How do we determine the direction of the trend for our purposes Simple. To a quotblankquot chart add a 200 EMAclose0 shift indicator. See chart 1 below. Looking from left to right at the 200 EMA on the H1 GBPUSD chart it is clear that direction has been going up since around October 7, thus, until the direction of the 200 EMA noticably changes, we will only be taking long trades, that is, only trades above the white 200 EMA line. UPDATE: I am finding the MA crosss work very well on countertrend trades on lower TFs also. just monitor more closely and dont necessarily look for as many pips as in a trend trade. Lets look at the H1 EURUSD chart for practice in determining direction. (chart 2 below) Again, the direction has been going up since approximately October 7. Go through this exercise on other pairs to get more practice in determining direction. (Note: If you are trading from a higher TF as an H4 chart, you would use the 200 EMA on that higher TF to determine direction.) Finishing setting up the trading chart . To the blank chart with the 200 EM A add the following Smoothed MAs: --- 3 Smoothed MAclose0 shift gold --- 8 SmoothedMAclose0 shift purple See chart 3 in next post After the chart is set up, make sure to save the template . SUMMARY OF THE quotRULES quot Big Picture for direction comes from the H1 chart (or higher if trading another TF, but drawdown will be significantly bigger the higher TF one uses) Scan for direction of 3,8 Smoothed MAs in relation to desired direction. Make note of pairs setting up or need later review, for example, if they are approaching the 200 EMA. what will they do Bounce off the 200 and turn, go through it, or walk along it. Those are the only choices. When 3 crosses 8 on higher TF. move to lower TF for entry . look for a strong cross on lower TF and enter. I monitor the trade on the higher TF . but that is a trader preference. Attached Images (click to enlarge) I right there with you Lawgirl. Once you get over the fear of losing and you can trust your own intentions, making money at Forex can be simple and fun. Heres a little envelope MA cross template of my own that I use every so often. No candles, just follow the white line and stay on the right side of the trend. How much easier can it be Hey forexhard, nice to hear about you, Im very new in FF cause I was reading but never getting involved in the forum, however i will from now on since its incredible the amount of kwnoledge you can get out of FF. I was reading the stairsteps thread, pretty nice system yet powerful, cant wait to markets open just to try it out on demo of course. I was thinking, what about a 100pips SL looking for a 1000pips profit Sounds crazy lets skype: elchinoazul This looks interesting. Definitely be demoing it this week. Even in a consolidation phase, if you exit when the 3 and 8 cross your losses will be minimal compared to the times when you win. Plus, it saves on wear and tear of the ole eyeballs There was a fellow on here who suggested this strategy: quotgo in with 2 or 3, and when you hit 50, sell two and bring the stop loss up to break even and let the third one runquot until the 3 and 8 cross again. Its a great strategy because youve eliminated greed. and the runner is a free trade Thats a definitely a good idea. Do you use microlots (0.01) or minilots (0.1)MACD (Moving Average ConvergenceDivergence Oscillator) MACD (Moving Average ConvergenceDivergence Oscillator) Introduction Developed by Gerald Appel in the late seventies, the Moving Average ConvergenceDivergence oscillator (MACD) is one of the simplest and most effective momentum indicators available. The MACD turns two trend-following indicators, moving averages. into a momentum oscillator by subtracting the longer moving average from the shorter moving average. As a result, the MACD offers the best of both worlds: trend following and momentum. The MACD fluctuates above and below the zero line as the moving averages converge, cross and diverge. Traders can look for signal line crossovers, centerline crossovers and divergences to generate signals. Because the MACD is unbounded, it is not particularly useful for identifying overbought and oversold levels. Note: MACD can be pronounced as either Mac-Dee or M-A-C-D. Here is an example chart with the MACD indicator in the lower panel: Calculation The MACD Line is the 12-day Exponential Moving Average (EMA) less the 26-day EMA. Closing prices are used for these moving averages. A 9-day EMA of the MACD Line is plotted with the indicator to act as a signal line and identify turns. The MACD Histogram represents the difference between MACD and its 9-day EMA, the Signal line. The histogram is positive when the MACD Line is above its Signal line and negative when the MACD Line is below its Signal line. The values of 12, 26 and 9 are the typical setting used with the MACD, however other values can be substituted depending on your trading style and goals. Interpretation As its name implies, the MACD is all about the convergence and divergence of the two moving averages. Convergence occurs when the moving averages move towards each other. Divergence occurs when the moving averages move away from each other. The shorter moving average (12-day) is faster and responsible for most MACD movements. The longer moving average (26-day) is slower and less reactive to price changes in the underlying security. The MACD Line oscillates above and below the zero line, which is also known as the centerline. These crossovers signal that the 12-day EMA has crossed the 26-day EMA. The direction, of course, depends on the direction of the moving average cross. Positive MACD indicates that the 12-day EMA is above the 26-day EMA. Positive values increase as the shorter EMA diverges further from the longer EMA. This means upside momentum is increasing. Negative MACD values indicates that the 12-day EMA is below the 26-day EMA. Negative values increase as the shorter EMA diverges further below the longer EMA. This means downside momentum is increasing. In the example above, the yellow area shows the MACD Line in negative territory as the 12-day EMA trades below the 26-day EMA. The initial cross occurred at the end of September (black arrow) and the MACD moved further into negative territory as the 12-day EMA diverged further from the 26-day EMA. The orange area highlights a period of positive MACD values, which is when the 12-day EMA was above the 26-day EMA. Notice that the MACD Line remained below 1 during this period (red dotted line). This means the distance between the 12-day EMA and 26-day EMA was less than 1 point, which is not a big difference. Signal Line Crossovers Signal line crossovers are the most common MACD signals. The signal line is a 9-day EMA of the MACD Line. As a moving average of the indicator, it trails the MACD and makes it easier to spot MACD turns. A bullish crossover occurs when the MACD turns up and crosses above the signal line. A bearish crossover occurs when the MACD turns down and crosses below the signal line. Crossovers can last a few days or a few weeks, it all depends on the strength of the move. Due diligence is required before relying on these common signals. Signal line crossovers at positive or negative extremes should be viewed with caution. Even though the MACD does not have upper and lower limits, chartists can estimate historical extremes with a simple visual assessment. It takes a strong move in the underlying security to push momentum to an extreme. Even though the move may continue, momentum is likely to slow and this will usually produce a signal line crossover at the extremities. Volatility in the underlying security can also increase the number of crossovers. The chart below shows IBM with its 12-day EMA (green), 26-day EMA (red) and the 12,26,9 MACD in the indicator window. There were eight signal line crossovers in six months: four up and four down. There were some good signals and some bad signals. The yellow area highlights a period when the MACD Line surged above 2 to reach a positive extreme. There were two bearish signal line crossovers in April and May, but IBM continued trending higher. Even though upward momentum slowed after the surge, upward momentum was still stronger than downside momentum in April-May. The third bearish signal line crossover in May resulted in a good signal. Centerline Crossovers Centerline crossovers are the next most common MACD signals. A bullish centerline crossover occurs when the MACD Line moves above the zero line to turn positive. This happens when the 12-day EMA of the underlying security moves above the 26-day EMA. A bearish centerline crossover occurs when the MACD moves below the zero line to turn negative. This happens when the 12-day EMA moves below the 26-day EMA. Centerline crossovers can last a few days or a few months. It all depends on the strength of the trend. The MACD will remain positive as long as there is a sustained uptrend. The MACD will remain negative when there is a sustained downtrend. The next chart shows Pulte Homes (PHM) with at least four centerline crosses in nine months. The resulting signals worked well because strong trends emerged with these centerline crossovers. Below is a chart of Cummins Inc (CMI) with seven centerline crossovers in five months. In contrast to Pulte Homes, these signals would have resulted in numerous whipsaws because strong trends did not materialize after the crossovers. The next chart shows 3M (MMM) with a bullish centerline crossover in late March 2009 and a bearish centerline crossover in early February 2010. This signal lasted 10 months. In other words, the 12-day EMA was above the 26-day EMA for 10 months. This was one strong trend. Divergences Divergences form when the MACD diverges from the price action of the underlying security. A bullish divergence forms when a security records a lower low and the MACD forms a higher low. The lower low in the security affirms the current downtrend, but the higher low in the MACD shows less downside momentum. Despite less downside momentum, downside momentum is still outpacing upside momentum as long as the MACD remains in negative territory. Slowing downside momentum can sometimes foreshadows a trend reversal or a sizable rally. The next chart shows Google (GOOG) with a bullish divergence in October-November 2008. First, notice that we are using closing prices to identify the divergence. The MACD039s moving averages are based on closing prices and we should consider closing prices in the security as well. Second, notice that there were clear reaction lows (troughs) as both Google and its MACD Line bounced in October and late November. Third, notice that the MACD formed a higher low as Google formed a lower low in November. The MACD turned up with a bullish divergence with a signal line crossover in early December. Google confirmed a reversal with resistance breakout. A bearish divergence forms when a security records a higher high and the MACD Line forms a lower high. The higher high in the security is normal for an uptrend, but the lower high in the MACD shows less upside momentum. Even though upside momentum may be less, upside momentum is still outpacing downside momentum as long as the MACD is positive. Waning upward momentum can sometimes foreshadow a trend reversal or sizable decline. Below we see Gamestop (GME) with a large bearish divergence from August to October. The stock forged a higher high above 28, but the MACD Line fell short of its prior high and formed a lower high. The subsequent signal line crossover and support break in the MACD were bearish. On the price chart, notice how broken support turned into resistance on the throwback bounce in November (red dotted line). This throwback provided a second chance to sell or sell short. Divergences should be taken with caution. Bearish divergences are commonplace in a strong uptrend, while bullish divergences occur often in a strong downtrend. Yes, you read that right. Uptrends often start with a strong advance that produces a surge in upside momentum (MACD). Even though the uptrend continues, it continues at a slower pace that causes the MACD to decline from its highs. Upside momentum may not be as strong, but upside momentum is still outpacing downside momentum as long as the MACD Line is above zero. The opposite occurs at the beginning of a strong downtrend. The next chart shows the SampP 500 ETF (SPY) with four bearish divergences from August to November 2009. Despite less upside momentum, the ETF continued higher because the uptrend was strong. Notice how SPY continued its series of higher highs and higher lows. Remember, upside momentum is stronger than downside momentum as long as its MACD is positive. Its MACD (momentum) may have been less positive (strong) as the advance extended, but it was still largely positive. Conclusions The MACD indicator is special because it brings together momentum and trend in one indicator. This unique blend of trend and momentum can be applied to daily, weekly or monthly charts. The standard setting for MACD is the difference between the 12 and 26-period EMAs. Chartists looking for more sensitivity may try a shorter short-term moving average and a longer long-term moving average. MACD(5,35,5) is more sensitive than MACD(12,26,9) and might be better suited for weekly charts. Chartists looking for less sensitivity may consider lengthening the moving averages. A less sensitive MACD will still oscillate abovebelow zero, but the centerline crossovers and signal line crossovers will be less frequent. The MACD is not particularly good for identifying overbought and oversold levels. Even though it is possible to identify levels that are historically overbought or oversold, the MACD does not have any upper or lower limits to bind its movement. During sharp moves, the MACD can continue to over-extend beyond its historical extremes. Finally, remember that the MACD Line is calculated using the actual difference between two moving averages. This means MACD values are dependent on the price of the underlying security. The MACD values for a 20 stocks may range from -1.5 to 1.5, while the MACD values for a 100 may range from -10 to 10. It is not possible to compare MACD values for a group of securities with varying prices. If you want to compare momentum readings, you should use the Percentage Price Oscillator (PPO). instead of the MACD. Adding the MACD Indicator to SharpCharts The MACD can be set as an indicator above, below or behind a security039s price plot. Placing the MACD behind the price plot makes it easy to compare momentum movements with price movements. Once the indicator is chosen from the drop-down menu, the default parameter setting appears: (12,26,9). These parameters can be adjusted to increase sensitivity or decrease sensitivity. The MACD Histogram appears with the indicator or can be added as a separate indicator. Setting the signal line to 1, (12,26,1), will remove the MACD Histogram and the signal line. A separate signal line, without the histogram, can be added by choosing Exp Mov Avg from the Advanced Options Overlays menu. Click here for a live chart of the MACD indicator. Using the MACD with StockCharts Scans Here are some sample scans that StockCharts members can use to scan for various MACD signals: MACD Bullish Signal Line Cross. This scan reveals stocks that are trading above their 200-day moving average and have a bullish signal line crossover in MACD. Also notice that MACD is required to be negative to insure this upturn occurs after a pullback. This scan is just meant as a starter for further refinement. MACD Bearish Signal Line Cross. This scan reveals stocks that are trading below their 200-day moving average and have a bearish signal line crossover in MACD. Also notice that MACD is required to be positive to insure this downturn occurs after a bounce. This scan is just meant as a starter for further refinement. Further Study: From the creator, this book offers a comprehensive study to using and interpreting MACD. Technical Analysis - Power Tools for Active Investors Gerald Appel