Inlägg

Kontaktar enskilt via PM, kommer stänga annonsen vid slutfört köp, men kortet är kvar i skrivande stund.

Köpte till slut ett 3080 och säljer därför mitt Gigabyte 1070 G1 Gaming 8GB. Fungerar felfritt. Kortet har endast använts till gaming (ingen mining).

Skickas via postnord och köpare står för frakt. Kan även hämtas i norra stockholmsområdet efter arbetstid.

Betalning görs via swish.

Läs hela annonsen här

Sure. Tycker dock personligen det är både enklare att skriva och läsa om man använder 2 separata tal i en struct, så därför såg jag ingen anledning till att "floatfiddla" ens i en skoluppgift. Jag har bränt mig på liknande genvägar förr när jag gjorde skoluppgifter/tävlingsprogrammering (speciellt innan jag hade en bra förståelse av flyttal).

Men det är nog tycke och smak, man vet själv vad man skriver snabbast

Heh, jag har sett roligare hack än så när jag pluggade

Jag skulle också kört på en struct (vilket är samma som en class i c++, fast med public members by default, om jag inte minns fel?...). Går ju att implementera '<'-operatorn samt '=='-operatorn på några rader kod bara så kan man använda stdlib-funktioner sen.

Folk här har säkert generellt god koll på floats, men skriver följande varning ändå:

Att använda floating point för att spara data på det föreslagna kreativa sättet kan straffa sig senare om/när man börjar lite mer komplicerade operationer, pga avrundingsfel. Spelar iof egentligen inte någon större roll om man vill lösa en skoluppgift på ett hackigt sätt, men jag skulle svära högt om någon gjorde det i kod som ska köras i prodmiljöer (eller ja... om det fanns en fet kommentar som förklarade nyttan med att spara data på det sättet så skulle jag ha överseende ).

Exempel nedan (dock java, men spelar ingen roll) för att visa på hazards med att spara saker på kluriga sätt i floats som bygger på att man har exakt sparade värden.

class Main {
  public static void main(String[] args) {
    double offset = 21.13;
    double x = 1.1 + offset;
    x -= offset;
    double y = 1.1;
    System.out.println(x);
    System.out.println(y);
    System.out.printf("X equals Y? : %s\n", x == y);
  }
}

Output:

1.1000000000000014
1.1
X equals Y? : false

Tack för testerna Sweclockers!

Uppskattar att ni gör tester med fokus på vilken cpu som flaskar mest och med mer verklighetstrogna uppsättningar (lär vara få personer som inte kör minnen i åtminstone 3000MHz).

Brukade läsa mycket på Anandtech innan de började med autospelande videos; det är kul att se mer nishade/fokuserade artiklar här på sweclockers med och inte bara på engelska sidor.

Håller med till 100%. Speciellt delen om att ha helst kvar ekosystemet men använda ett annat språk än Java (Kotlin?). Hur mycket quality of life features som än läggs in i Java, så kommer det inte bli lika bra/snyggt som ett språk som har dessa från början. Men ekosystemet är väldigt nice att jobba med, och Java får jobbet gjort åtminstone.

Man bör också imo, komma ihåg att det inte var allt för länge sedan Microsoft inte var ett open source-kramande företag med cloudvänliga produkter/platformar. Det finns alltid risker med att använda ett språk/platform som kontrolleras av ett företag.

Ja...Oracle gillar att använda advokater för att dra in pengar tyvärr :/. Men det ledde åtminstone till att Kotlin blev anammat av Google som ett officiellt språk till Android. Vore nice om man kan använda Kotlin i vanliga backendapplikationer i högre utsträckning, och inte bara Android.

Men aja, som upprepats gång på gång i tråden så är språket inte det viktiga. Man dras mot de språk/ekosystem som ger en vettiga verktyg och är nice att använda, det är en ren pragmatisk fråga. Om java någon dag blir legacy så betyder det förhoppningsvis att det finns något bättre att använda istället

Håller med om att javaEE är på väg att bli (eller kanske redan är, oracle har slutat att göra releaser) legacy. Jag har jobbat i lite drygt 3 år utan att koda javaEE öht (om man inte innefattar spring som javaEE, men det är en rätt stor stretch).

På javasidan är det däremot fullt av liv och rörelse med stora företag som netflix, google och twitter som internt kör på java/jvmbaserade språk och bidrar med kod till open source. Oracle har också skruvat upp utvecklingstakten på java, och gör fler releaser oftare med nya features (vilket verkligen behövdes, var ett stort tidsglapp efter java8 där ingenting hände). Jag ser greenfieldprojekt runt mig som görs i java, och att allt mindre av dessa görs på gamla javaEE-platformar (ofta proprietära produkter sålda av oracle, redhat, m.fl) vilket är väldigt nice :).

Arbetar själv för tillfället med en nyskriven spring boot applikation som deployas med docker mot molnmiljöer, så känner att du har en aning skev bild av vart javavärlden är på väg.

@Thorvald

Ett praktiskt tips: om du vill koda java, använd för guds skull IntelliJ som IDE, och inte eclipse (dunno om någon använder det numera?...Har inte stött på någon på jobbet som använder eclipse på något år). Skillnaden i användarupplevelse är dramatisk, intellij är mycket mer välpolerad.

När jag pluggade så fanns det möjlighet till att få studentlicens till IntelliJ Ultimate via mitt lärosäte. Huvudanledningar till att använda ultimate istället för community edition (gratisversionen) är
1) Stöd för javascript/typescript och de största frontendramverken (code completion, söka efter definitions av saker, mm)
2) Stöd för Spring Boot (ett av de mer populära javaramverken), smidigt för att skapa run configurations som används för att köra igång applikationen från IDEn

Det finns säkert många som föredrar en specifik IDE för frontend/javascript, men intellij ultimate funkar bra om man vill göra all kodning (hela stacken) i samma IDE.

Jag jobbar med utveckling i java sedan ett antal år tillbaka efter ha blivit klar med studier. Vad @Xelithium sa stämmer, speciellt i början (när man jobbat längre så börjar man samla på sig mer specialiserad kunskap om ramverk o dylikt som är knutna till ett visst språk). Fokusera på att lära dig 'programmeringstänket' som redan skrivet.

Ett mer direkt svar på din fråga:
Java och C# har skillnader, men är i mycket lika varandra. Det verkar finnas direkta motsvarigheter för allt (språk features, libraries mm). Det största hindret för att hoppa mellan C# och java tror jag är ekosystemen (ramverk, byggsystem, körmiljöer, IDE:er, m.fl). Dessa saker lär man sig inte i en handvändning, men har man lärt sig dem i ena språket tror jag det är rätt straightforward att byta om man lägger ner lite möda på fritiden.

For what it's worth så verkar flertalet företag inom finans (banker, fintech, osv) jag hört talas om köra javateknikstack, men något enstaka verkar använda C#, men det är anekdotisk data. Men tror inte du går arbetslös vare sig du fokuserar på java eller C# i början, viktigast är att lära sig programmera först

Jag hittar inte någonstans i psyonix pressrelease att det ska bli borttaget från steam. Förutsätter att det kommer fortsättas säljas där. Oklart var sweclockers har fått den infon ifrån, källhänsvisning vore bra..

Imo så är det positivt att ett spel kommer till så många store:s som möjligt, att ingen enskild store har ensamrätt på ett spel. Så att RL även släpps till epic store är positivt. Psyonix har ändå nydligen lagt in stöd för både crossplatform play och att man göra party:s mellan olika platformar (dvs köra tillsammans med polare även om denne kör från switch och du kör från PC), det borde fungera på samma sätt med epic store.

Kan bli tråkigt med steam workshop dock, kan bli lite splittring var custom content läggs upp. Frågan är, påverkar det custom trainings? Om inte så bryr jag mig inte nämnvärt.

Sorry, jag kan nog bli bättre på att förklara vad jag menar, var något otydligt det jag skrev.

Du påstod att syftet med swap är att förbättra prestanda, vilket jag inte håller med om (förutom undantagsfallet att man kan cacha filer i RAM med minne som frigjorts mha swappning av inaktivt minne).

Att använda swap kan omöjligt förbättra prestanda genom att låta 'rätt' saker vara inladdade i RAM. För om man har stängt av swap helt så kommer det inte längre vara en issue vilka delar av virtuella minnet som ligger på disk och vilka som ligger i RAM då ALLT virtuellt minne ligger inladdat i RAM. Får delar av applikationen inte plats i RAM så kommer saker istället att krasha, det är allt eller inget som gäller.

Syftet med swap är att låta applikationer använda mer minne än det finns RAM samt att undvika systemkrasher när RAM tar slut. Sen är frågan hur man uppnår det med så lite prestandaförluster som möjligt, alltså hur OS:et väljer vilka delar av minnet som swappas ut. Där kan det teoretiskt uppstå prestandaförluster redan vid låg användingsgrad på minnet om heuristisken är dålig eller olämplig för den applikation man använder. I ett sådant fall kan man stänga av swap för att kringå detta (dock med problem vid full minnesanvändning som följd).

Jag tror inte det stämmer att swap används till att ladda in "viktigare" saker i RAM? För utan swap så kan det endast finnas 2 möjligheter: antingen får du plats med hela applikationen i minnet eller så krashar applikationen pga för lite minne (eller annan slumpvald applikation, eller hela systemet, om man har otur... :/).

Snarare är det väl det man brukar använda "överblivet RAM" (ledigt för att det inte används, eller frigjort genom swappning) till att cacha filer? Cachning av filer är nice för vanlig användning, men heuristiken (speciellt avvägningen: ha kvar gamla pages i minne VS ladda in filer i cache) som används lär inte vara optimerad för spelande i första hand. I teorin (dunno om det är ett problem i praktiken) skulle det kunna bli en mismatch vad OS:et (windows/linux whatever) är optimerat för, och konsekvenser det får för spel.

Misstänker personligen dock att prestandapåverkan för spel är väldigt låg, om någon negativ påverkan finns öht.

Jag håller med om att man inte alltid vill använda SPA:er, då SPA:er alltid innerbär ökad komplexitet då det är ett extra lager abstraktion. När jag skrev att det var standard med SPA:er så tänkte framförallt på nyutveckling, och framförallt på program/system med många och/eller komplexa krav och som kommer att vidareutvecklas över tid. För mindre saker finns det stora fördelar att välja det man är mest van vid, och gärna det enklaste verktyget som får jobbet gjort.

YMMW ofc, men jag har iaf inte stött på (på jobbet) några stora greenfieldprojekt som gjorts med templating under de senaste 2 åren, det är mestadels spring boot + angular/react på javasidan.

Om du vill lära dig att programmera bättre utan att göra saker onödigt komplexa så föreslår jag förresten följande projekt:

Testa att skriva en egen httpserver, gör den så enkel som möjligt. HTTP är ett textbaserat protokoll, så allt kan göras mha manipulering av strängar. Om du skriver den i Java, se följande exempel för hur man lyssnar på nätverkconnections & skriver text till anslutningar)

Det är imo viktigt att inse att mycket av det som görs av moderna ramverk inte är "magi", utan egentligen saker som skulle kunna skrivas manuellt varje gång, men som man gärna slipper... Man ska IMO inte vara helt hjälplös utan 3:departs-libraries om man ska kunna anse sig själv vara en "bra programmerare".

@RobinJacobsson Ser att det finns lite förvirring gällande webbapplikationer kring skillnaden mellan ramverk frontend vs backend, och vilka språk dessa ramverk använder (vilket är normalt, det är mycket att in som ny på området). Så tänkte försöka ge lite bakgrund/större bild kring det. Jobbar till vardags med backendutveckling i java.

Historiskt så har man gjort webbapplikationer (tex sweclockers.com) i backend + html-templating (& javascript för mindre grejer: animationer, live uppdatering av data för visualisering mm). Exempel på templating-teknologier är PHP, där du bäddar in phpkod (backendkod) direkt i en htmlsida. Du får alltså in data från från databaser/filer/"whatever datakälla du har" till användaren genom att trycka in datan direkt i html-sidan som skickas från backend.
Det finns motsvarande templating-möjligheter i alla stora backendspråk, men dessa teknologier är ofta upp mot 20 år gamla och många av dem är legacy idag (java har tex JavaServer Pages från 1999, men det är legacy idag och används inte för nya projekt, finns ingen anledning att lära sig det).

Sedan några år tillbaka så är standard att bygga webbapplikationer i helt separerade backend och frontend delar. Det betyder att man frångått templating på webbservern (backend), och istället skriver ett webbgränssnitt som är helt oberoende (i teorin iaf...). Ingen data hårdkodas i html-filerna från backend, all data laddas istället via http-anrop (vanligtvis i formatet json).

Eftersom webbgränssnittet (frontend) är oberoende backend så har det sin egen teknikstack. För webbläsare är det alltid JavaScript som gäller, som vanligtvis kombineras med ett ramverk, det vanligaste är i dagsläget React som folk här nämnt. Man använder ramverk i frontend för att få struktur i koden & features utan att behöva implementera dem själv, gång efter gång.

Anledningen till att man använder ramverk för backend (tex Spring Boot som är populärt för nyskrivna webbapplikationer skrivna i java) är samma anledning som frontend ovan, man vill få en tydligare programstruktur och slippa behöva återuppfinna features som generella för alla webbapplikationer (e.g. hur du ansluter till databaser, skickar html-filer via http till användare, authensiering av användare/inloggning, etc etc).