Men allvarligt, vad är det som gör att jag plötsligt får en sådan här inbjudan? Inkomsten har varit densamma i flera år, kvinna är jag född som, men möjligen kan Porsche ha insett att en viss grupp medelålders kvinnor med bra inkomst faktiskt är potentiella förare av denna gamla statussymbol, vars rykte som lyxartikel börjar bli litet slitet. När de gamla, manliga köparna sviker måste man hitta en ny kundgrupp, och vips, duger kvinnorna!

Alltså. det är bara en tanke. Om man vill, så finns det roligare teorier: Efter Monas väskflash har en helt ny marknad för lyxkonsumtion öppnat sig, som tidigare bara gynnat Haléns postorder, fiskeaffärer, Grosshandlar´n, SAAB, K-Rauta, COOP, Kapp-Ahl, Grolls och Björnkläder.

När jag var 12 år drogs jag med av min mamma till Kungsan där vänsterpartiet samlades på 1 maj. Fy för den lede, utropade jag i bästa Lizzie-stil, folk ser slafsiga och äckliga ut. Om vi ska demonstrera (det skulle man om man var ensamstående storstadsmorsa på 70-talet, det var väl mycket bra ragg i leden …) kan vi väl gå till Humlegården istället, snälla mamma? Där ser de iallafall snygga och propra ut. Socialdemokraterna samlades i Humlan, allvarliga, välklädda i bästa söndagskostymen. Det gillade jag.

I förr veckan läckte Moderaternas nya profil ut. Där fanns allt, både om vilka ord man skulle undvika och använda, loggor, färger och den numera berömda klä-dig-som-folk-maualen.

Inte oväntat haglade de roade kommentarerna i sociala media som Twitter och Facebook. Här är några axplock:

Jag tycker moderater får ha på sig precis vad de vill. Däremot tycker jag en hel del om vad deras regeringspolitik. Det är viktigare att diskutera hur man beter sig som folk än hur man klär sig som folk…

Men om jag ska ge ett råd så är nog färgen orange, som Alliansen tagit till sin egen, kanske inte den symbolmässigt mest lämpliga. Enligt Wikipedia är den minst sagt kontroversiell: “Orange utlöser mer kontrovers än någon annan färgton. Det förknippas ofta med något starkt negativt eller positivt /…/ Mörkorange kan betyda svek och misstro. Rödorange motsvarar begär, /…/ dominering, aggression och längtan efter handling. /…/ Orange representerar frosseri i kristendomen.”

Nu är det uppochnervända världen. moderaterna anbefaller kavaj och pärlhalsband av, och sossar ses drista sig att bära väskor som det inte står Konsum på. Ur led är tiden…Mannen som gav rutiga flanellskjortan ett namn, Göran Greider, tycker till och med att väskan hotar hela socialdemokratin.

Imorgon är jag och Stig Malm från Solna kallade till valfotografering inne i stan. Vi har fått klädorder. Det är kavaj, slips, dräkt och halsband på. Haha, skojade bara!

Men moderaternas kampanjstab står tomhänt inför den imponerande hipster-armé av artister och kulturpersoner i Acnejeans som kommit ut som sossar, skriver Karin Olsson i Expressen. Sossarna – so hip it hurts. Nej, tror inte det. Senast jag var på Riksdagens s-kansli hade de flesta män kavaj och damerna nåt liknande, fast i brokigt möbeltyg.

Men vad ska jag ha på mig när jag representerar partiet? Jag letar i kallelsen till fotograferingen, men jag hittar inga andra råd än att jag ska ha mörka kläder, detta dock inte av någon mer spännande anledning än att den vita texten på affischerna ska synas. Ingen vägledning där alltså… suck. Måste nog skriva och fråga Magdalena Ribbing. Jag kanske ska skrälla i flanellskjorta, bygghjälm och skinnväst imorgon? Nästan litet queer… (S)ex & the City-prylen är ju redan gjord. Här syns jag på sq2540sthlm:s ekomodevisning på eventet Vote! In the name of fashion

Och här är en länk till ungdomar.se där man i en tråd diskuterar hur personer från olika partier ser ut. Riktigt rolig!

We use MySQL on most of our projects. One of these projects has a an access pattern unlike any other I’ve worked on. Several million records a day need to be written to a table. These records are then read out once at the end of the day, summarised and then very rarely touched again. Each record is about 104 bytes long (thre’s one VARCHAR column, everything else is fixed), and that’s after squeezing out every byte possible. The average number of records that we write in a day is 40 million, but this could go up.

A little bit about the set up. We have fairly powerful boxes with large disks using RAID1/0 and 16GB RAM, however at the time they only had 4GB. For BCP, we have a multi-master set up in two colos with statement level replication. We used MySQL 5.1.

My initial tests with various parameters that affect writes showed that while MyISAM performed slightly better than InnoDB while the tables were small, it quickly deteriorated as the table size crossed a certain point. InnoDB performance deteriorated as well, but at a higher table size. The table size turned out to be related to the innodb_buffer_pool_size, and that in turn was capped by the amount of RAM we had on the system.

I decided to go with InnoDB since we also needed transactions for the summary tables and I preferred not to divide my RAM between two different engines. I stripped out all indexes, and retained only the primary key. Since InnoDB stores the table in the primary key, I decided that rather than use an auto_increment column, I’d cover several columns with the primary key to guarantee uniqueness. This had the added advantage that if the same record was inserted more than once, it would not result in duplicates. This small point was crucial for BCP, because it meant that we did not have to keep track of which records had already been inserted. If something crashed, we could just reinsert the last 30 minutes worth of data, possibly into the secondary master, and not have any duplicates at the end of it. I used INSERT IGNORE to get this done automatically.

Now to get back to the table size limit that we were facing. Initial tests showed that we could insert at most 2100 records per second until the table size got to a little over the innodb_buffer_pool_size and at that point it degraded fairly rapidly to around 150 records per second. This was unacceptable because records were coming in to the system at an average rate of 1000 per second. Since we only needed to read these records at the end of the day, it was safe to accumulate them into a text file and periodically insert them in bulk. I decided to insert 40,000 records at one time. The number I chose was arbitrary, but later tests that I ran on batches of 10K, 20K and 80K showed no difference in insert rates. With batch inserts, we managed to get an insert rate of 10,000 records per second, but this also degraded as soon as we hit the limit going down to 150 records per second.

System stats on the database box showed that the disk was almost idle for most of the run and then suddenly shot up to 90-100% activity once we hit this limit, so it was obvious that at this point, the DB was exchanging data between buffers and disk all the time.

At this point, someone suggested that we try partitioning, which was available in MySQL 5.1. My first instinct was to partition based on the primary key so that we could read data out easily. However, reads weren’t really our problem since we had no restriction on how fast they needed to be (at least not as much as writes). Instead, I decided to partition my table based on the pattern of incoming data.

The first part was obvious, use a separate table for each day’s data. On a table of this size, DROP TABLE is much faster than DELETE From <table> Where ..., and it also reclaims lost space. I should mention at this point that we used file_per_table as well to make sure that each table had its own file rather than use a single innodb file.

Secondly, each table was partitioned on time. 12 partitions per day, 2 hours of data per partition. The MySQL docs for Partitioning were quite useful in understanding what to do. The command ended up looking like this:

    CREATE TABLE (        ...    ) PARTITION BY RANGE( ( time DIV 3600 ) MOD 24 ) (        Partition p0 values less than (2),        Partition p1 values less than (4),        Partition p2 values less than (6),        Partition p3 values less than (8),        Partition p4 values less than (10),        Partition p5 values less than (12),        Partition p6 values less than (14),        Partition p7 values less than (16),        Partition p8 values less than (18),        Partition p9 values less than (20),        Partition p10 values less than (22),        Partition p11 values less than (24)    ); 

The time field is the timestamp of incoming records, and since time always moves forward (at least in my universe), this meant that I would never write to more than 2 partitions at any point in time. Now, a little back of the envelope calculations:

    44M x 102 bytes = approx 4.2GB    2x for InnoDB overhead = approx 8.4GB     +10% for partitioning overhead = 9.2GB    /12 partitions = approx 760MB per partition 

This turned out to be more or less correct. In most cases total table size ranges between 8-10GB, sometimes it goes up to 13GB. Partition sizes range from less than 700MB to over 1GB depending on the time of day. With 4GB of RAM, we had an innodb_buffer_pool set at 2.7GB, which was good enough to store two partitions, but not good enough to work on any other tables or do anything else on the box. Boosting the RAM to 16GB meant that we could have a 12GB buffer pool, and leave 4GB for the system. This was enough for 2 partitions, even if the total number of records went up, and we could work on other tables as well.

After partitioning, tests showed that we could sustain an insert rate of 10K rows per second for some time. As the table size grew past 10 million records, the insert rate dropped to about 8500 rows per second, but it stayed at that rate for well over 44 million records. I tested inserts up to 350 million records and we were able to sustain an insert rate of around 8500 rows per second. Coincidentally, during Michael Jackson’s memorial service, we actually did hit an incoming rate of a little over 8000 records per second for a few hours.

One more BotE calculation:

    8500 rows per second  x  86400 seconds per day = 734.4 Million records per day

Considering that before this system was redesigned it was handling about 7 Million records per day, I’d say that we did pretty well.

Varje dygn använder omkring en av 1000 stockholmare kokain. Den uppskattningen gör Olof Beck, adjungerad professor i analytisk klinisk farmakologi på Karolinska, som har analyserat avloppsvattnet i Stockholm.

Innedrogen går att följa från toaletter och handfat, i de södra förorterna såväl som på Stureplan, till reningsverket i Henriksdal. På reningsverket har man samlat in vattenprover i två tunnlar. I den ena rinner vatten från innerstaden, i den andra från Stockholms södra förorter. Det är TV4:s Kalla fakta som står bakom studien –den första i Sverige.

–Det är ordentliga halter och inga problem med att mäta kokainmängden i vattnet, säger Olof Beck.

Han arbetar även med att analysera drogtester från arbetsplatser. Siffrorna från avloppsstudien pekar på ett lika stort användande som arbetsplatstesterna, säger han.

Men avloppsstudien är en liten studie, för att få säkra resultat krävs att prover samlas in under en längre tidsperiod.

–Det här är en pilotstudie, inte någon fullskalig vetenskaplig undersökning, säger Lasse Wierup, journalisten som gjort reportaget.

Men han menar att siffrorna snarare är en underskattning än en överskattning av antalet kokainanvändare och säger att det går att dra vissa slutsatser av studien.

–Vi kan se att stockholmarna använder mindre kokain än människor i till exempel Rom och London, men att vi ligger på ungefär samma nivå som München och Frankfurt.

Halten av kokain och nedbrytningsämnet bensoylekognin i vattnet är ett halvt mikrogram, eller 0,0000005 gram, per liter. Det utgör ingen fara för människor eller miljö.

–Ingen narkotika jag känner till utgör någon fara i vattnet, ämnena bryts ned. Det man kan oroa sig för är läkemedel som innehåller hormoner och som inte bryts ned.

Lasse Wierup är även aktuell som författare till boken Kokain som lanseras den kommande veckan. Till boken har han intervjuat ett antal kokainanvändare.

Han säger att många av dem är medvetna konsumenter som inte vill stödja industrier där människor utnyttjas eller far illa. Men kokainet är ett undantag.

– De är förvånansvärt ointresserade av kokainets bakgrund, trots att det är en industri som finansierar mord och står för ett otroligt cyniskt utnyttjande av människor.

Så här såg webbsidorna ut 1996

Publicerad den 20. Mar, 2010 av Peter i Internet

Hur såg webbsidorna ut 1996? Man blir ganska förvånad när man ser hur idag framgångsrika företags webbsidor såg ut i Internets begynnelse!

Jag läste två intressanta artiklar vilka ledde fram till den här artikeln. Den första var en artikel ifrån Gizmodo – Old Websites Sure Are Funny och den andra var Internet 96 vilka båda två handlade om hur en del stora företag som McDonald’s, Coca Cola, Lego med flera tog sina första stapplande steg på webben i mitten på 90-talet.

Det var ärligt talat inte mycket till webbsidor i början men webbsidor 1996 var inte direkt utvecklade med samma teknik och funktioner som idag och kan se ganska intetsägande och ganska trista ut, men som sagt det var 1996 och en hel del har förändrats sedan dess. Här är några stora företags cachade webbsidor hur de såg ut 1996 och hur de ser ut idag 2010.

Lego 1996

Lego 2010

Coca Cola 1996

Coca Cola 2010

Pepsi 1996

Pepsi 2010

McDonald’s 1996

McDonald’s 2010

Reebok 1996

Reebok 2010

Nintendo 1996

Nintendo 2010

Dell 1996

Dell 2010

HP 1996

HP 2010

Yahoo 1996

Yahoo 2010

Microsoft 1996

Microsoft 2010

Vill ni själva se hur olika webbsidor såg ut tidigare kan man göra det via WayBackMachine, och säkert hittar ni massvis med gamla intressanta och roliga versioner av olika webbsidor.

Inspiration – Gizmodo och msu.edu – Internet 96

Andra bloggar om: Webbsidor, Cachade webbsidor, 1996, WayBackMachine

Tags: Internet, Webbsidor