av ·0 kommentarer

Dagligen i mitt arbete finns där ett behov av att spara ned screenshots, om så bara för mig själv för framtida kom-ihåg, eller för att dela med kollegor, chef, uppdragsgivare eller annat.

Screenshot via Prt sc (printscreen) knappen på tangentbordet och Paint i Windows

I början var min go-to då att använda ”Prt sc”-knappen på tangentbordet för att ta en screenshot.

Pro Tip: Håll nere Alt-knappen samtidigt som du tar din screenshot/skärmdump för att begränsa screenshotten till din enstaka aktiva skärm – om din setup har flera skärmar!

Och därefter klistra in i Microsoft Paint (Windows) för att sen antingen spara direkt, eller använda Paints beskärningsverktyg för att begränsa vad som syns på screenshotten.

Beskärningsverktyget i Microsoft Paint Windows (7)

Rensa bort känsligt material från skärmdump / screenshot

Ibland vill man ju kanske inte exponera alla sina flikar i t ex. ett webbläsarfönster man har uppe, eller undvika exponera filer på skrivbordet i bakgrunden, eller liknande.

Privacy är underskattat i dagens samhälle, men bör tas på allvar, när man nu väl har en möjlighet. Alla behöver inte veta allting.

Ibland kan det även fokusera budskapet att använda markeringsverktyg för att cirkla in det man vill motpart ska fokusera på, och rensa bort ”klutter” från det man delar för att få ett fokuserat budskap.

Alternativt sätt att öppna Microsoft Paint i Windows

Ett annat tips om ni inte har Microsoft Paint fäst i aktivitetsfältet (startbaren) nere på er Windows-dator så kan man alltid öppna sökrutan och skriva in ”mspaint” likaså för att söka upp programmets körbara fil för att öppna Microsoft Paint :)

av ·0 kommentarer

På sistone har det hänt att jag har behövt felsöka PHP loggfiler eller HTTP loggfiler p.g.a. att hemsidan kanske kraschat via PHP Fatal Error eller p.g.a. DDoS-attacker.

DDoS-attacker mot hemsidor och vad man kan göra när de inträffar

DDoS-attacker är vanligare än man kanske tror och kanske mer så för populära och större hemsidor – tyvärr.

Det finns tillochmed företag inom affärsvärlden som anlitar folk för att sänka konkurrenter genom att ha dem skicka ut kodade bottar för att överbelasta hemsidor på olika sätt.

Ofta brukar detta dock vara olagligt, men kanske inte alltid så lätt att spåra ursprunget och komma fram till vem som ligger bakom.

Jag har erfarenhet av att ha stött på bottar utskickade från andra länder, kodade att överbelasta hemsidan på olika sätt.

En bot kan relativt enkelt (tyvärr) överbelasta en hemsida

En av de här bottarna gjorde det genom att låta botten basically ”klicka runt” på hemsidan så snabbt som bottens maskins processor klarade av.

Och vår server kunde inte hänga med.

Tänk dig själv hundratals- om inte tusentals klick på millisekunden på din hemsida. Där varje klick motsvarade anrop till servern, för handling som behövde tas av den.

Anrop som ofta involverade SQL-frågor till databasen, JavaScript funktioner att laddas och köras eller sidor att generera och laddas.

Det krävs inte ”rocket science” att lista ut att detta lätt överbelastar en servermaskins RAM-minne, processorkraft och övriga resurser, som annars delas mellan alla besökare till en hemsida.

Och skapar köer så långa att hemsidan till slut blir otillgänglig medan servern försöker hantera belastningen den utsatts för.

Om man tänker efter så behöver det inte vara så komplicerat att bygga något som kan förstöra för en hemsida, men det är synd att folk gör det och att det är så lätt för dem att åstadkomma det och komma undan med det.

Där finns en väldigt bra bok jag köpte för några år sen och läste för Hur man bygger Spiders, Bottar osv. skriven av en som arbetade professionellt med att enbart bygga bottar för olika affärsändamål som företag hade behov av.

Det kunde vara ändamål som att indexera priser från konkurrenters hemsidor, eller automatisera testkörning av formulär på olika hemsidor, och liknande.

Men då varje bot du bygger kommer köra så snabbt som processorn klarar av – om du inte säger till den något annat- så hade denna författaren som best praxis och regel alltid när han byggde bottar att ”simulera en människans beteende”.

Med detta menas för när en människa besöker hemsidor och hur ”fort” de då gör olika saker på en hemsida.

Han simulerade detta genom att lägga in någon sekunds delay mellan varje datahämtning.

  • Dels för att inte skada servern för hemsidan han arbetade mot med sina bottar
  • Dels då det är olagligt att krascha hemsidors servrar
  • Dels för att vara ”under radarn” och inte ge kanske konkurrenter osv. anledning att kolla närmare på hans bott och dess beteende

Boken är ”Webbots, Spiders, and Screen Scrapers: A Guide to Developing Internet Agents with PHP / CURL” av Michael Schrenk.

webbots, spiders, and screen scrapers bok av Michael Schrenk

Kan varmt rekommendera boken för alla er nyfikna på hur man bygger Bot programvara med PHP. Enklare än man tror, på gott och ont.

Om inget annat så kan boken öppna ögonen och utöka förståelsen för vad en bot faktiskt kan åstadkomma på en hemsida, och hur, vilket även kan hjälpa till när du ska analysera och skydda dig från dem.

”Know Thy Enemy” som en vis man en gång sade, lite så.

Motverka DDoS och liknande attacker med Cloudflare och liknande tjänster

Ett populärt sätt att motverka detta som jag hört talas om men ännu inte haft möjligheten att implementera och testa själv är tjänster som Cloudflare som ska sätta upp en form av ”skyddsnät” framför din hemsida ut mot Internet som är tränad att känna igen- och kunna blockera dåligt beteende innan det når din faktiska hemsida och dess server.

Har hört många tala väldigt gott om det och att det ibland tillochmed talats om att vara typ ett av de- om inte det- bästa sättet att faktiskt skydda sig mot DDoS och liknande otrevligheter.

Förebygg framtida DDoS-attacker genom HTTP Access logganalys och IP-blockering

Alternativet brukar annars vara att man typ får gräva ned sig i loggfilerna och försöka identifiera IP-adresser som beter sig märkligt i HTTP Accessloggarna för att sen placera en IP-block för den typen av besökare i serverns brandvägg där hemsidan är hostad.

Men detta är också oftast något som upptäcks isf. och görs i efterhand vilket då brukar innebära att det är ”för sent” och skada redan kan ha skett.

När jag grävde i våra PHP-loggfiler för en plattformsbaserad hemsida så märkte vi att där genererades väldigt stora PHP loggfiler p.g.a. t ex. att PHP-version uppdaterats och vissa kodbitar för vissa tredjepartsmoduler osv. kanske inte var helt 100% anpassade vilket ledde till ofantligt många PHP notice osv. vilket kladdade ned hela PHP loggfilen och bidrog till enorma filstorlekar.

Det gick tillochmed så långt att filstorleken överskridit vad programmet jag brukar använda: TextPad – som jag btw varmt kan rekommendera för dig som arbetar i Windows miljö! – Klarade av att hantera, så hela datorn nästan hängde sig eller tog oändligt lång tid för att öppna filerna.

Splitta stora textfiler till flera mindre för att kunna öppna dem

Jag brukar samarbeta med erfarna utvecklare som stött på liknande problem tidigare och de tipsade mig då om GSplit och File Splitter tjänster/programvara, som är då designade att ta större textfiler, och dela upp dem i flera mindre textfiler.

När jag Googlade på det hittade jag även en StackOverflow tråd om hur man kunde åstadkomma detta med Git likaså.

Så istället för att ha en Loggfil på kanske 5 GB (ja det har hänt), så kunde man Splitta upp den i 5 filer om 1 GB per styck istället.

Vilket då underlättade i sin tur för TextPad att faktiskt klara av att öppna loggfilen.

Ett bra tips! För alla er som någon gång stött på liknande problem, där ni behövt ladda ned från FTP loggfilerna för att felsöka och analysera trafik eller felmeddelande för en hemsida och råkat ut för så stora filer att ni knappt kunnat öppna dem.

Kör ni via terminalen vilket många webbutvecklare kanske gör (om de har access) så kanske detta inte är ett lika stort problem, då det brukar finnas kraftfullare hanteringsmetoder via SSH och terminalkommando, jämfört med t ex. Windows OS GUI.

Men det är inte alltid man faktiskt har access till SSH och kanske måste undersöka loggfiler (om man ens har access till dessa) och då kanske man blir tvingad att använda t ex. FileZilla FTP klient för att ladda ned för att sen kunna undersöka och analysera i en vanlig texteditor på sin dator.

av ·0 kommentarer

Flera gånger dagligen finner jag mig själv använda dessa två verktyg:

  • Skärmklippsverketyget
  • Klipp & Skissa

I skrivande stund på en dator med Windows 10 under mina arbetsdagar.

Det är ovärderliga verktyg som ersatte- för mig iaf.- PrtSc knappen på tangentbordet och mspaint (Microsoft Paint) genvägen för copy-paste och sen beskärningsredigering.

Screenshot hotkey tips

Om du vid något tillfälle skulle finna dig använde PrtSc knappen för att ta screenshot av något du önskar dela, ett tips – Använd ALT-knappen på tangentbordet för att begränsa en fler-skärms uppsättning till att bara ta en screenshot av den skärmen som just nu är aktiv.

Dela pedagogiska och precisa bilder med Windows Skärmklippsverktyget och Klipp & Skissa

De är verkligen supersmidiga verktyg i en webbutvecklares arbetsdag, kanske primärt p.g.a. deras funktion att markera valfritt screenshot-område sammankopplat med möjligheten att markera delar av screenshotten med röd eller annan färgad penna för tydlighet och pedagogik.

Effektivisera arbetsdagen och spara tid

Tyckte det var värt att lyfta de här såväl som liknande programvaror som kan effektivisera arbetsdagen och spara värdefull tid.

Användningsområden med dessa verktyg för mig själv inkluderar ofta att:

  • Ta screenshot via dem som sen automatiskt hamnar i urklipp för att kunna klistras in i Skype till partners
  • Såväl som i diverse chattapplikationer till kollegor
  • Eller e-post meddelanden

Värdefulla användningsområden för Skärmklippsverktyget och Klipp & Skissa

Eller bara för att spara ned för att ha som backup vid ändring man gör, eller för att dela designförslag, eller visa upp något man märkt.

Där finns många användbara och bra sätt att använda de här programmen i din arbetsdag.

Hur du använder programmen

Lyckades gräva fram en manual för Skärmklippsverktyget för både Windows 10 och 11.

Såväl som en PDF från Uppsala Seniornet.se som demonstrerar användning av Klipp & Skissa verktyget.

Parallell användning för ännu effektivare arbete

Har tillochmed märkt en fördel med att alternera användningen av de båda parallellt, då jag kanske använt den ena men ej har behovet/lusten att spara som en fil det jag fångat, däremot behöver jag fortfarande ha det uppe ibland under en period, och då kan det dyka upp nytt behov under denna period då jag hade behövt ta en ny screenshot.

Det är då här det andra programmet kommer in så jag kan alternera smidigt.

av ·0 kommentarer

Stötte på ett intressant fall där jag höll på att sätta upp en webbserver för en hemsida.

För att göra detta behövde jag kopiera över både en FTP backup såväl som en SQL backup för databasen då sidan hade existerat annanstans tidigare så det basically var som ett serverbyte.

By default för inleed.se när man sätter upp en Apache webbservrar verkar där från början ligga en index.html fil innan man lagt in sina egna filer i rotmappen för domänen som man kopplat på.

Efter att jag packat upp min FTP backup så fanns där nu både inleed.se’s index.html fil, såväl som min FTP backups index.php fil.

Jag antog att min index.php fil skulle skriva över deras index.html så därför rörde jag den inte initiellt.

Men där hade jag visst fel, verkar som att index.html hade företräde framför index.php.

Vi trodde först det kanske handlade om att HTML kanske hade företräde p.g.a. att det kom tidigare än PHP som kodspråk.

En intressant teori som jag själv tyckte ändå verkade rätt rimlig.

Sen dess har jag grävt vidare lite på egen hand och hittade det här Stackoverflow svaret om hur det är en serverkonfiguration som man ska kunna ändra.

Oavsett är det good-to-know ifall ni själva stöter på liknande scenario, eller bara som mig, är nyfikna och intresserade :)

Så därför tänkte jag dela denna observation och insikt.

av ·0 kommentarer

Idag satt jag och kollade på den här hemsidans temafiler för när man öppnar ett inlägg så det är i fokus (single.php).

På den här hemsidan använder jag ett tema, som jag inte längre tror är så lätt att få tag i, som heter ”Flat”, detta då den här sidan skapades för ganska längesen och temat valdes när sidan skapades.

Tips för att skapa Child Theme för din WordPress sida

Hursomhaver, så har jag gjort ett Child Theme för sidan, med hjälp av det fantastiskt smidiga WP pluginnet WordPress Child Theme Configurator som man bör som best praxis, för att undvika ev. förlust av ändringar man gör vid temauppdatering i framtiden.

Ändra temafiler i WordPress

Som kanske många av er vet så är WordPress temafiler kodade med kodspråket: PHP, och det blir därför detta kodspråk vi kommer använda för att fixa in kategorier till mina inläggs temafiler.

Steg 1 – Hitta rätt temafil att börja gräva i för vart man behöver ändra

När man vill ändra filer från huvudtemat i sitt child theme så får man gå till Utseende > Filredigeraren i WordPress adminpanelen och bläddra fram uppe i högra hörnet originaltemat och dess filer.

Steg 2 – Inspektion av koden för att hitta vart man behöver ändra

När man väl har huvudtemats filer uppe så kan man inspektera hur koden ser ut för t ex. single.php som i vårt fall var relevant då jag ville ändra hur hemsidan presenteras när någon besöker ett specifikt inlägg på sidan.

Väl där inne möttes jag av följande kod:

single.php screenshot för mitt flat wordpress tema

Som ni kan se ovan så visar WordPress temaredigerare ”Enskilt inlägg” för min single.php.

Likaså kan ni se i själva koden get_template_part() WordPress funktionen som anropas som jag strukit under.

Denna funktion laddar in en annan template fil inuti den jag befinner mig i- och där koden är skriven (single.php i det här fallet).

I detta fall verkade temafilen content-single.php laddas in.

Steg 3 – Hitta koden vi behöver redigera

Så då letade jag upp denna för att inspektera hur den såg ut, då jag kunde se i single.php inte hade det jag ville komma åt att ändra – vilket i det här fallet var att lägga till kategorier intill mina taggar i slutet av inlägget.

content-single.php screenshot

Som vi kan se i ovan bild, så hittade jag det jag letade efter i content-single.php, nämligen DIV-elementet med class ”tags-links” som höll mina taggar i slutet av inlägg när besökt.

Remote FTP som alternativ för att enkelt arbeta med WordPress temafiler

Alternativ till ovan WordPress redigererare kan man ta fram hemsidans FTP via antingen FileZilla FTP client, eller någon form av Remote FTP som ex. den jag använder via min Notepad++.

Med Remote FTP behöver du bara:

  1. ”öppna” (ladda ned) filen efter du kopplat upp dig mot sidans FTP
  2. Göra dina ändringar
  3. Sen trycka CTRL + S för att spara (beroende på texteditor)

Därefter kommer ändringar automatiskt och direkt skickas upp till din hemsida så du kan se resultaten av din kod Live (på gott och ont).

Det kan dock vara bra att vara lite vaksam när man arbetar med Remote FTP, då session ibland kan disconnectas vid inaktivitet en längre tid.

Om det händer kan det hända att man behöver spara ändringarna i filen flera gånger, för att göra det kanske man behöver lägga till ”asd” eller annat godtyckligt så ens texteditor känner igen en ändring i filen för att tillåta omsparande, och kanske göra det 1-2 gånger. Så behöver jag iaf. göra i Notepad++ oftast vid disconnect.

Likaså kan det vara bra om man är flera som arbetar i samma filer att man håller lite koll på vem som sparar upp ändringar när och laddar ned filer de ska jobba i när, för det är lätt hänt att någon kan ha laddat ned samma fil som du vill jobba i tidigare, och gör ändringar i den för att sen synka upp till sidan, men när du laddar upp dina ändringar för den då äldre filen så skrivs deras ändringar över.

Detta extra viktigt att hålla koll på om man inte har Versionshantering via t ex. Git och GitHub eller liknande.

Kan varmt rekommendera Remote FTP för att göra temafilsändringar hellre än att hålla på att Ladda ned fil från t ex. FileZilla FTP klient, redigera, sen ladda upp manuellt.

Steg 4 – Redigera vår överskrivna temafil till så som vi vill ha det

Härifrån sen var nästa steg att skriva över denna content-single.php filen i mitt child theme.

Detta då jag ville göra egna ändringar till den för att komplettera hur den såg ut i nuläget för att forma hur inlägget ser ut till såsom jag ville ha det.

Steg 4.1 – Skapa override filen i vårt child theme

Så jag skapade content-single.php i samma mapp som mitt child theme (då temafilen inte låg inuti någon undermapp i huvudtemat).

Steg 4.2 – Kopiera över koden från huvudtemats temafil till override filen i child temat

Därefter kopierade jag koden från huvudtemats content-single.php fil till min nyskapade child theme content-single.php fil.

Steg 4.3 – Research för att ta reda på vad som behövs för att göra ändringar vi vill göra

Jag googlade lite för att hitta en WordPress funktion som det verkade som att andra tidigare använt för att göra det jag ville, get_the_category().

Steg 4.4 – Börja göra ändringarna och testa utfallet

Sen lade jag in en ny DIV-behållare för mina inläggskategorier och skapade inuti en foreach-loop för varje kategori så jag kunde formatera det i form av länkar som var klickbara.

kodändringar content-single child theme fil screenshot

Notera att detta basically bara är ”crude” test för att få det såsom jag vill. Exempelvis är ”Kategorier” inte kodat för flerspråkighet om man vill ha det, osv.

Jag hade också kunnat skippa flera echo statements och bara skrivit HTML-koden såsom resten av temafilen för övrigt var kodad. Men nu fick det bli såhär för just denna gång :)

PHP koden:

count(get_the_category())

Anropade jag bara för att testa om

  1. Det gick att räkna antalet kategoriobjekt med count() i PHP, bara som en kontroll om WPTerm Array funkade som vanliga PHP-arrayer, för det är inte nödvändigtvis givet
  2. Som förebyggande inför en viss typ av formatering jag först funderade på för sidan där jag tänkte ha kategorierna flödande utskrivna med komma-separerat emellan (förutom sista) vilket isf. hade kunnat fixas med en if-sats som kollade när loopen ej befann sig på sista och då skrev ut kommatecken i slutet efter länken för kategorin med hjälp av en counter-variabel i och med att vi använde oss av en foreach loop i just det här specifika fallet
Testa utfallet av anrop till ”nya” funktioner som man inte ännu är så bekant med genom printouts

Om man vill utforska mer i detalj returen från get_the_category() så hade man kunnat använda PHP’s var_dump() eller print_r() funktioner för att outputta returen på ett strukturerat och hyfsat lättläsligt vis på sidan för inspektion.

Tips för test på Live-sidor vid behov – fast som ej syns för besökare

Om man gör detta på en Live-sida kanske man inte vill att besökare ska kunna se att man håller på och testar, och då kan man istället ”wrappa” outputten i en style="display:none;" SPAN-tagg eller <pre>-block eller liknande.

Exempel:

<span style="display:none;">
   <?php echo print_r(get_the_category()); ?>
</span>
Hitta snabbt printout i koden med Google Inspector

Om man snabbt vill hitta det man outputtat i t ex. Google Code Inspector så hade man kunnat tilldela output elementet ett ID, en klass eller annat som är unikt på sidan så man via CTRL + F kommer direkt dit.

Steg 4.5 – Komplettera med CSS-Styling för utseende

Sen nästa steg att komplettera med lite CSS kod som ser ut som följer för att få det såsom jag ville ha det:

/*
* 24sept24
* */
.single-post div#cats-links {
   border-top: 1px solid #ccc;
   padding-top: 12px;
   margin-top: 40px;
   font-size: 14px;
}

.single-post div#cats-links a {
   color: #000;
   background-color: #eee;
   padding: 4px 10px;
   margin-right: 6px;
   margin-bottom: 6px;
   display: inline-block;
   padding-bottom: 1px;
   border: 1px solid #ccc;
}

.single-post .tags-links {
   font-size: 14px;
   margin-top: 10px !important;
}

.single-post .tags-links a {
   padding-bottom: 2px !important;
   border: 1px solid #ccc;
   color: #000;
}

.single-post #cats-links a:hover {
   background-color: #333;
   color: #fff;
}

Som ni kan se i ovan CSS-kod så har jag använt pixlar för måttenheter i just detta exempel av pedagogiska skäl då jag tycker det är lättast att förstå ”hur stort” det är, jämfört med relativa måttenheter som är baserade på annat mått procentuellt.

Inline-block som jag tilldelat till mina A-länktaggar är för att kunna applicera bl. a. margin-bottom då enbart inline-element inte tar det.

Färgkombinationerna var trial-and-error för att komma fram till, blev helt i extas när jag hittade kombon som är just nu som jag tyckte funkade alldeles utmärkt, jag kan tycka färgkombinationer är svårt och kräver ofta mycket experimenterande från min sida. Sen är ju smaken som baken också såklart.

Tips att använda ”failsafe” CSS-selektor för att begränsa CSS-kods applikationsområde

Ni kanske också märker jag lagt in en ”failsafe”-klass framför samtliga av mina regler jag lagt till mitt child themes ”Extra CSS”.

I just det här fallet för ”single-post”, vilket är en BODY-tagg klass som alltid finns när någon besöker ett inlägg på sidan, vilket garanterar att koden jag utformat enbart appliceras på just dessa sidor.

Kommentera datum/tid för ändring för kronologisk minneshjälp vid kodningsarbete

Notera också min kommentar med dagens datum i mitt speciella datumformat för CSS-tillskotten jag lade till, detta är mest för min egen skull för att ha ett hum om när vad tillkom i min CSS fil.

Jag upplever att det ger en form av kronologisk struktur som i kombination tillsammans med mitt eget minne skapar en tidslinje som kan hjälpa mig komma ihåg varför jag gjorde saker, när jag gjorde dem. Vilket kan vara ett vanligt förekommande problem att inte komma ihåg inom programmering osv. Därav kommentarer och deras funktion.

Ibland kompletterar jag även kommentaren om jag känner att det kan behövas, typ vid specialfix osv. Men i just det här fallet tyckte jag CSS-selektorer var ganska självförklarande och ansåg då det inte behövdes :)

För övrigt gillade jag designen med knapp-liknande klickbara både taggar och kategorier.

Visdom från UX guru Jakob Nielsens rekommendationer för mobilanvändare med touchscreen

Jag har alltid i bakhuvudet Jakob Nielsens UX best praxis rekommendation för mobilanvändare med att fingerblomman mätts upp till ca. 16x16px för klickytor på touchscreens, men i det här fallet gick jag faktiskt lite utanför denna rekommendationer och körde på mitt eget för att få något jag tyckte såg trevligt ut oavsett hur det var i förhållande till UX best praxis för mobil smartphone användare.

Kanske får justera för det i framtiden, men just nu får det vara som det är.

Såklart bör man alltid utveckla för att inkludera alla användare, eller åtminstone användare man riktar sig till och för att öppna upp för målgrupper, men ibland kan man göra temporära medvetna kompromisser i mån av brist av tid och prioritet i stunden.

I slutändan brukar man dock vid ett eller annat tillfälle komma tillbaka och fixa :)