A classic read about Test Doubles: Martin Fowler’s Mocks Aren’t Stubs.
–jeroen
Archive for March, 2016
Martin Fowler’s “Mocks Aren’t Stubs” – recommended reading
Posted by jpluimers on 2016/03/31
Posted in Agile, Development, Software Development, Unit Testing | Leave a Comment »
Some links on recovery of drives on LSI megaRAID controllers.
Posted by jpluimers on 2016/03/30
Some links on recovery of drives on LSI megaRAID controllers.
- Everything About Everything: Tech Support from the Trenches: Computer Beeping on Startup.
- windows server 2008 r2 – LSI RAID-on-chip with RAID6 over two SAS links goes red when HDD enclosure is powered cycled; how to recover? – Server Fault.
- LSI MEGA Raid Controller: RAID1 Rebuild nach HDD Wechsel – Mein Blog – Mein Blog.
- Spezialist für LSI Megaraid gesucht | Grillforum und BBQ – www.grillsportverein.de.
- Ramblin’ Dude: MegaRAID.
- CentOS – LSI Raid and MegaCli Command | Linuxorz.
- MegaRaid – vellum – Technical articles and sample code – Google Project Hosting.
- LSI RAID Controller – Hetzner DokuWiki.
- MegaCLI cheatsheet | ErikIMH – just another linux admin’s blog.
–jeroen
Share this:
Posted in LSI/3ware, Power User, RAID | Leave a Comment »
Some links on SSD RAID
Posted by jpluimers on 2016/03/29
In the future, I need to add my own experience as well. For now some links:
- Short stroking is the process by which the capacity of a volume is reduced in order to improve drive performance. There are benefits to short stroking any mechanical disk, regardless of whether the drives are used in any type of RAID array.via Short-Stroke: Why, and how….
- LSI 9260-8i w/ 6 256gb SSDs – RAID 5, 6, 10, or bad idea overall? – Server Fault.
- RAID Creation, Test Setup, And Throughput – Another Record Broken: 6 Gb SAS, 16 SSDs, 3.4 GB/s!.
- Intel SSD 520 RAID Review | StorageReview.com – Storage Reviews.
- LSI 9260-8i – poor random read/write performance with SSDs? | ServeTheHome and ServeThe.Biz Forums.
–jeroen
Share this:
Posted in Hardware, LSI/3ware, Power User, RAID, SSD | Leave a Comment »
Two opinions on Netflix and blocking: they hate Netflix or contact tr@netflix.com and try to solve …
Posted by jpluimers on 2016/03/28
Basically there are two opinions on Netflix and blocking:
- TL;DR: People use VPNs for security, Netflix fucks them up, they hate Netflix for that and just torrent that shit.
- tl;dr If you have issues with Netflix on public Wifi, contact the provider and forward tr@netflix.com to them so they can settle issues.
I’m not a netflix user (or user of any form of DRM) as I really dislike the fact that DRM means for any reason your license can be ended. I’ve seen too many players going out of business or taking decisions turning.
So I buy CDs, DVDs, BlueRays or DRM-free media files. Now it’s my problem of making proper back-ups to ensure future access to them (:
The DRM walls and ladders war^w game has gone so far that in this case, Netflix is blocking even though the WiFi provider / proxy / VPN is in the same country like the below imgur image:
Share this:
Posted in Cloud, Infrastructure, Netflix, Network-and-equipment, Power User, VPN | Leave a Comment »
difference between ADSLfiber and fiberfiber when both are @xs4all.
Posted by jpluimers on 2016/03/28
20150412 ping statistics from WiFi -> ADSL -> VPN -> fiber (where ADSL and fiber both are Fritz!Box machines having LAN-LAN VPN to each other):
PING 192.168.71.1 (192.168.71.1): 56 data bytes
64 bytes from 192.168.71.1: icmp_seq=0 ttl=63 time=19.190 ms
...64 bytes from 192.168.71.1: icmp_seq=1 ttl=63 time=18.905 ms
64 bytes from 192.168.71.1: icmp_seq=2 ttl=63 time=19.261 ms
64 bytes from 192.168.71.1: icmp_seq=3 ttl=63 time=19.982 ms
64 bytes from 192.168.71.1: icmp_seq=4 ttl=63 time=19.332 ms
64 bytes from 192.168.71.1: icmp_seq=5 ttl=63 time=26.800 ms
64 bytes from 192.168.71.1: icmp_seq=6 ttl=63 time=20.139 ms
64 bytes from 192.168.71.1: icmp_seq=7 ttl=63 time=19.498 ms
64 bytes from 192.168.71.1: icmp_seq=8 ttl=63 time=18.915 ms
64 bytes from 192.168.71.1: icmp_seq=9 ttl=63 time=19.200 ms
64 bytes from 192.168.71.1: icmp_seq=10 ttl=63 time=18.948 ms
64 bytes from 192.168.71.1: icmp_seq=11 ttl=63 time=19.524 ms
64 bytes from 192.168.71.1: icmp_seq=12 ttl=63 time=19.511 ms
64 bytes from 192.168.71.1: icmp_seq=13 ttl=63 time=20.417 ms
64 bytes from 192.168.71.1: icmp_seq=14 ttl=63 time=19.350 ms
64 bytes from 192.168.71.1: icmp_seq=15 ttl=63 time=18.690 ms
64 bytes from 192.168.71.1: icmp_seq=16 ttl=63 time=18.632 ms
64 bytes from 192.168.71.1: icmp_seq=17 ttl=63 time=18.912 ms
64 bytes from 192.168.71.1: icmp_seq=18 ttl=63 time=19.397 ms
64 bytes from 192.168.71.1: icmp_seq=19 ttl=63 time=19.257 ms
64 bytes from 192.168.71.1: icmp_seq=20 ttl=63 time=18.147 ms
64 bytes from 192.168.71.1: icmp_seq=21 ttl=63 time=18.601 ms
^C
--- 192.168.71.1 ping statistics ---
22 packets transmitted, 22 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.147/19.573/26.800/1.657 ms
same but LAN –> fiber -> VPN -> ADSL
Pinging 192.168.24.1 with 32 bytes of data:
Reply from 192.168.24.1: bytes=32 time=19ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Ping statistics for 192.168.24.1:
Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 19ms, Average = 17ms
–jeroen
Share this:
Posted in ADSL, fiber, Fritz!, Fritz!Box, Internet, Network-and-equipment, Power User, routers, VPN | Leave a Comment »
The Wiert Corner - irregular stream of stuff 