GeirGrusom Skrevet 2. november 2012 Rapporter Del Skrevet 2. november 2012 (endret) .NET er laget i samme ånd som Java, altså at du ikke kompilerer programmet til native code, men til en virtuell maskin, som deretter kompileres til den plattformen som programmet skal kjøre på under kjøring, etter behov. Derfor kan du skrive et program i C#, og uten engang å rekompilere kan du flytte fra 32-bit til 64-bit, og deretter til Arm om du skulle ønske det. Du kan tilogmed bytte operativsystem (dersom programmet er skrevet med det i tankene) grunnet at det i utgangspunktet ikke er noen plattformspesifikk kode i et .NET program. Høres bra ut, men hvor stabilt er det? Med andre ord, hvor plundrete blir det? Jeg har aldri hatt stabilitetsproblemer med .NET. Istedet for å lage en skikkelig C++ kompilator med 64-bit støtte, så hiver Embercardero seg på en bølge for å trekke med seg programmerere som ikke har fått med seg at det er svært vanskelig å leve av å lage mobil-apper. Endret 2. november 2012 av GeirGrusom Lenke til kommentar
vebbiii Skrevet 2. november 2012 Rapporter Del Skrevet 2. november 2012 Hvilke programmer brukere dere for versjonskontroll? Jeg brukte tidligere svn, men har gått over til git etter hvert. Det var en del problemer med svn når jeg brukte det, ser ut som git er hakket bedre, dog synes jeg det er unødvendig komplisert. Så en artikkel på et nettsted der svn og git ble sammenlignet SVN: Git: Lenke til kommentar
tomsi42 Skrevet 2. november 2012 Rapporter Del Skrevet 2. november 2012 Hvis du har brukt SVN tidligere, og ønsker noe kraftigere, men enklere enn git, så vil jeg anbefale en titt på mercurial. Lenke til kommentar
Matsemann Skrevet 2. november 2012 Rapporter Del Skrevet 2. november 2012 Til enkel, vanlig bruk er git og svn veldig likt. Update&commit(&push). Git trenger ikke være så alt for komplisert så lenge en holder seg unna det. En trenger som regel kun de avanserte tingene om en har rotet for mye med de avanserte tingene.. Den git-tegningen overkompliserer veldig. Du trenger sjeldent forhold deg til annet enn pull, commit, push og evt. skifte/merge branch. Dessuten tar den for seg at man har et lokalt repo i tillegg til serveren sitt, noe en sjeldent trenger å tenke på. Her har de i tillegg tatt med _enda_ et repo man har forka og skal pulle til. Det kommer du ikke til å bruke til privat utvikling, brukes i hovedsak i open source prosjekter der folk kan jobbe på koden uten å ha tilgang til "master", og så kan noen som sitter på master inkludere dine endringer om de er gode nok. Blæh, rot. Uansett ikke lett å sammenligne forskjellige VCS. Svn og Git er fundamentalt forskjellige siden den ene er distribuert og den andre ikke, med de fordeler og ulemper det medfører. Lenke til kommentar
vebbiii Skrevet 2. november 2012 Rapporter Del Skrevet 2. november 2012 (endret) Først og fremst er jo noe av det viktigste hvordan systemet håndterer konflikter. Pull og push(commit) er jo greit nok, det hånderer jo de fleste rimelig greit, med unntak av svn som lager ørten forskjellige versjoner av de forskjellige filene. Hvis du har brukt SVN tidligere, og ønsker noe kraftigere, men enklere enn git, så vil jeg anbefale en titt på mercurial. Takk for tipset, skal sjekke det ut Endret 2. november 2012 av vebbiii Lenke til kommentar
Gjest Slettet+9871234 Skrevet 3. november 2012 Rapporter Del Skrevet 3. november 2012 (endret) Istedet for å lage en skikkelig C++ kompilator med 64-bit støtte, ... Som nevnt ovenfor. Hastverk kan være lastverk. Når den blir (er?) ferdig, tviler jeg ikke på at det blir en av de beste 64 bits C++ kompilatorer i verden. ,.. så hiver Embercardero seg på en bølge for å trekke med seg programmerere som ikke har fått med seg at det er svært vanskelig å leve av å lage mobil-apper. Hva bygger du det på? Så det at det er vanskelig å leve av lage mobil-apper skulle hindre Embarcadero i å lage gode krysskompatible løsninger for mobile platformer? Hvilke programmer brukere dere for versjonskontroll? Da kan jeg anbefale for deg boken Drupal 7 Mobile Web Development Beginner’s Guide kapittel 2: http://www.packtpub..../book#chapter_2 The two major SCM systems in use today are Subversion (SVN) and GIT. SVN is the older and more established version management system. However, recently, the entire Drupal community has moved to GIT, so for this example, we will use GIT. The primary difference between the two is that Subversion has a single-parent structure. There's an SVN repository that is authoritative for any given project. Every other instance is a "local checkout," and every time code is committed, the changes must be checked into the primary parent repository. It is a tree that has a single trunk. GIT is known as a distributed version management system. Each GIT repository has no dependency on network access or any other repository. You can check files in and commit them to your local version without updating any remote version. The emphasis with GIT is on speed and non-linear development. It's very easy to branch a GIT repository (take the project in a completely new direction). GIT also has the concept of pushes and pulls. When you're making a change and you want the change to be reflected in all copies of the repository, you push your changes out. When you're gathering changes others have made, you're pulling data from one or more origins. There are several commercial SCM suites available and many corporate programming environments purchase commercial software and have it tailored to their specific development needs. For our project and our needs, GIT will be more than sufficient. So, the question now becomes, what do we manage? It seems silly to version manage the entire Drupal installation because everything, with the exception of a few files from the theme and custom modules, can be downloaded directly from drupal.org and remains unchanged from the version management system drupal.org. Well, that problem is solved by a system called Drush and Drush's companion project, Drush Make. With Drush and Drush Make, we can describe a version of the Drupal core and a series of projects (modules) and libraries that make our own custom distribution of Drupal. You may think that this is a lot of "command-line stuff", particularly if you're a frontend developer and used to using a GUI for all of your work. But stay with me; I promise there's a method to my madness and the time you spend learning the command line will pay off. In the final chapter, we'll show you how to roll that distribution with deployment scripts and create Drupal instances that build themselves with a few clicks of the mouse. Min utheving i rødt. Drupal samfunnet har altså funnet GIT mer enn godt nok. Kanskje et sterkt argument for å bruke GIT. Endret 3. november 2012 av Slettet+9871234 Lenke til kommentar
GeirGrusom Skrevet 4. november 2012 Rapporter Del Skrevet 4. november 2012 Istedet for å lage en skikkelig C++ kompilator med 64-bit støtte, ... Som nevnt ovenfor. Hastverk kan være lastverk. Når den blir (er?) ferdig, tviler jeg ikke på at det blir en av de beste 64 bits C++ kompilatorer i verden. ,.. så hiver Embercardero seg på en bølge for å trekke med seg programmerere som ikke har fått med seg at det er svært vanskelig å leve av å lage mobil-apper. Hva bygger du det på? Så det at det er vanskelig å leve av lage mobil-apper skulle hindre Embarcadero i å lage gode krysskompatible løsninger for mobile platformer? Kanskje. Jeg bare synes det er ganske svakt å være eneste C++ compiler uten 64-bit støtte med unntak av Open Watcom når AMD64 som instruksjonssett har vært tilgjengelig siden 2000. Her er det ikke snakk om hastverk er lastverk, men helt klart en økonomisk grunn til at det ikke er blitt gjort. Når det gjelder mobilutvikling så er det vel sikkert flott at de laget dette for å funke på alle mobilplattformer. Hvordan løser de dette egentlig for iOS? Det er imot retningslinjene til Apple å utvikle iOS programvare på noe annet enn Apple maskinvare, og både Unity og Xamarin må brukes på Macintosh dersom man skal bruke iOS som plattform. Lager Embarcardero IDE-et og kompilatorer for OS X også? Lenke til kommentar
Gjest Slettet+9871234 Skrevet 5. november 2012 Rapporter Del Skrevet 5. november 2012 (endret) Kanskje. Jeg bare synes det er ganske svakt å være eneste C++ compiler uten 64-bit støtte med unntak av Open Watcom når AMD64 som instruksjonssett har vært tilgjengelig siden 2000. Her er det ikke snakk om hastverk er lastverk, men helt klart en økonomisk grunn til at det ikke er blitt gjort. De har da hatt en beta versjon så vidt jeg vet en god stund. Noen selskaper kvalitetssikrer kanskje sin programvare strengere enn andre. Apple er for eksempel strengere på å godta apper enn Google (Android). PHP 6.0 ser ut til å trekke ut i årevis på grunn av problemer med uni coding. PHP er vel ikke akkurat kjent for streng kvalitetssikring. Derimot tror jeg det er kvalitetssikring som gjøre at Embarcadero er seine med å lansere en ferdig 64 bits C++ kompilator. Men det bygger på synsing og ikke eksakt viten. Personer hos Alfasoft vet sikkert mer om grunnen. Når det gjelder mobilutvikling så er det vel sikkert flott at de laget dette for å funke på alle mobilplattformer. Hvordan løser de dette egentlig for iOS? Det er imot retningslinjene til Apple å utvikle iOS programvare på noe annet enn Apple maskinvare, og både Unity og Xamarin må brukes på Macintosh dersom man skal bruke iOS som plattform. Lager Embarcardero IDE-et og kompilatorer for OS X også? Dette må du spørre Embarcadero og ikke meg om. Endret 5. november 2012 av Slettet+9871234 Lenke til kommentar
vebbiii Skrevet 5. november 2012 Rapporter Del Skrevet 5. november 2012 Det viste seg at problemene jeg har hatt i git kom fra noen bugs jeg fikk når jeg importerte prosjektet. Etter å ha slettet prosjektet og lastet det inn igjen fungerer git utmerket Lenke til kommentar
Gjest Slettet+9871234 Skrevet 5. november 2012 Rapporter Del Skrevet 5. november 2012 (endret) Glimrende at du fikk GIT til å fungere og at du ser ut til å velge den programvaren. Om C++Builder 64-bit! Get a free upgrade to C++Builder 64-bit! Buy C++Builder or XE3 or RAD Studio XE3, new user or upgrade, and get a free upgrade to the C++Builder XE3 64-bit compiler as soon as it's available (expected December 2012). How to get it: Buy C++Builder XE3 or RAD Studio XE3, Professional edition or higher. When C++Builder XE3 64-bit is released, you will be able to download the upgrade at no cost from http://cc.embarcadero.com/reg/c_builder. You must install and register your purchased XE3 version prior to downloading the 64-bit upgrade. http://www.embarcadero.com/radoffer Endret 5. november 2012 av Slettet+9871234 Lenke til kommentar
tomsi42 Skrevet 10. november 2012 Rapporter Del Skrevet 10. november 2012 Apropos Delphi - OpenSoure klonen Lazarus har ednelig nådd versjon 1! Måtte jo laste ned og prøve ut. Det er jo som å komme hjem Da har jeg noe å finne på i høst/vintermørke kvelder. Lenke til kommentar
Gjest Slettet+9871234 Skrevet 3. desember 2012 Rapporter Del Skrevet 3. desember 2012 Jeg gjør oppmerksom på disse to: https://www.diskusjon.no/index.php?showtopic=1476827 https://www.diskusjon.no/index.php?showtopic=1477726 tråden for de som vil være i fronten på utvikling av nettsider og apper for mobile plattformer. Lenke til kommentar
GeirGrusom Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 Hva i helsike er poenget med workspaces i TFS? I går så hadde Drift meldt maskinen min ut av et av domenene for utvikling, som førte til at jeg mistet tilgang til TFS. Dette domenet skulle fjernes, fordi alle brukere skulle migreres. Jeg har nå fått en ny bruker, men den gamle brukeren har fortsatt mappen prosjektmappen, og jeg får ikke tatt vekk dette selv da brukeren ikke lenger eksisterer. Jeg fatter ikke poenget med at Team Foundation Server faktisk holder styr på hvem som har mappet hva, og hvor, og nekte den samme mappen fra å bli mappet på nytt. Argh! Irritasjon! Lenke til kommentar
tomsi42 Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 Høres ut som om TFS har tatt til seg enkelte av de dårligste sidene fra ClearCase. Jeg er glad vi bruker Mercurial her på huset. Lenke til kommentar
GeirGrusom Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 Høres ut som om TFS har tatt til seg enkelte av de dårligste sidene fra ClearCase. Jeg er glad vi bruker Mercurial her på huset. Skulle ønske vi hadde mercurial eller git her også, men TFS er ihvertfall greiere enn SVN og CVS (som de på den andre siden av kontoret faktisk bruker) Lenke til kommentar
Gjest Slettet+9871234 Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 Team Foundation Server (TFS), ClearCase samt Mercurial. Ukjent for meg. Har noen tid til å gi en kort forklaringe. Er det noe som bare brukes av større firmaer eller er det noe å se på for mindre firmaer? Lenke til kommentar
tomsi42 Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 Team Foundation Server (TFS), ClearCase samt Mercurial. Ukjent for meg. Har noen tid til å gi en kort forklaringe. Er det noe som bare brukes av større firmaer eller er det noe å se på for mindre firmaer? Kildekode systemer. TFS er en Microsoft variant, Clearcase var store før - og brukes nok av store firmaer. Mercurial er et moderne distribuert system - litt ala git. Git er nok kraftigere, mens mercurial har bedre GUI verktøy, særlig på Windows. Lenke til kommentar
Matsemann Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 Er nyttig i bruk selv som enkeltperson. Greit å lage en "branch" der en prøver ut noe, for så å evt. forkaste endringene eller kjøre de inn igjen i "master". Også greit å gå over dagens kode (sjekke "diff") og se hva en har gjort. Får en bedre følelse av fremgang, kan reviewe koden, fjerne debug stuff osv. Har man det på en ekstern server har man i tillegg en bra form for backup. På jobb bruker vi både git og svn. Ser ikke hvorfor svn får så mye hat mot seg. Ja, det er ikke distribuert. Når alle jobber in-house er ikke det et problem. Annerledes modell enn git mtp branching, stashing osv., men fungerer helt greit til bruken. Lenke til kommentar
GeirGrusom Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 (endret) På jobb bruker vi både git og svn. Ser ikke hvorfor svn får så mye hat mot seg. Ja, det er ikke distribuert. Når alle jobber in-house er ikke det et problem. Annerledes modell enn git mtp branching, stashing osv., men fungerer helt greit til bruken. SVN synes jeg er helt greit. Forstår heller ikke helt hvorfor det får så mye hat. Så for å gjøre det klart: andre siden av kontoret bruker CVS. Endret 7. desember 2012 av GeirGrusom Lenke til kommentar
tomsi42 Skrevet 7. desember 2012 Rapporter Del Skrevet 7. desember 2012 Jeg synes også SVN er greit. Liker å tenke på den som en Perforce light - vi brukte Perforce på jobben fra rundt 2001 til 2008. Som vi savnet lenge. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå