onsdag den 27. oktober 2010
De malede konkrete kunst af Jerome Soltan
6201 N. Kenmore
6011 N. Winthrop
Jeg har en dyb, mørk, beskidt, farlig hemmelighed at dele med jer alle:
Jeg kan godt lide Four-Plus-One.
Der, sagde jeg det! Jeg sagde det, og jeg er stolt! Jeg vil ikke tage det tilbage!
5617 N. Kenmore Ave.
5940 Kenmore Avenue - \ "Thorndale Beach West \" - sandsynligvis Jerome Soltan
Hvorfor jeg kan lide dem? Nå, C'mon. Hvordan kan nogen ikke lide bygninger med indgange som disse?
1060 W. Hollywood Avenue - Jerome Soltan
6110 N. Kenmore Avenue
6250 N. Kenmore - det samme design som 6110 Kenmore
Jeg har ikke en arkitekts navn for langt størstedelen af disse bygninger, men når jeg gør, er det næsten altid Jerome Soltan. Lidt berygtet som den oprindelige og mest formere udvikler af de fire-Plus-One lejlighedskompleks, er Soltan karakteristiske stil stemplet på næsten alle 4-Plus-1 i området syd for Loyola University, hvor de fleste af disse bygninger er beliggende. Han kan eller måske ikke har udviklet dem alle, men hans indflydelse kan ses i hver eneste.
5411 N. Winthrop Avenue
Behøver jeg påpege dejlige kreativitet entryways? Love 'em eller hader' em, de er helt sikkert udtryksfulde.
Det er klart, nogle af dem dukker op mere end én gang. Soltan var slet ikke flove over at genbruge sine designs, bare så længe de ikke var på samme blok.
5620 N. Kenmore - \ "The Chalet \" (det er naturligvis!) - Jerome Soltan
5450 N. Winthrop Ave. - Formentlig Jerome Soltan igen
6134 N. Kenmore Ave
6972 N. Sheridan Road - Jerome Soltan
6246 N. Kenmore - Canisius Hall, Loyola University - igen, formentlig Jerome Soltan
5851 N. Winthrop
6610-6628 N. Sheridan
6825 N. Sheridan - Jerome Soltan
6307 N. Winthrop Avenue - Xavier Hall, Loyola University
6128 N. Kenmore
6011 N. Kenmore
5953 N. Kenmore (til venstre) og 5949 N. Kenmore (til højre - \ "Thorndale Beach East \", Jerome Soltan
6030 N. Kenmore
5833 N. Kenmore
tirsdag den 26. oktober 2010
London Design Festival Starter dag
En ni-dages fejring af design og en platform for det bredest spektrum af design discipliner, samles som et unikt og tilgængeligt program. Ikke at gå glip: The Tramshed Event - en kraftfuld ... [[Dette er et indhold resumé kun. Besøg min hjemmeside for fuld links, andet indhold, og meget mere! ]]
fredag den 15. oktober 2010
Usaedvanlige gaver til hele familien
Den fælles varmedunk ser ud til at gøre det modsatte til en vis lodden pattedyr, der på denne tid af året er begyndt at overvintre. Indtil det sanser de første tegn på en chill, det lurer i hjørnet af nogle skab eller boks. Derefter voila! Den sidder der i bunden af sengen
Det er naturligvis noget vrøvl, men jeg ville bare understrege, at for de fleste af os varmt vand flasker. Jeg kan ikke engang huske sidste gang, at jeg faktisk købte en. det ville have sikkert været en sidste øjebliks julegave til en ældre slægtning.
Vi som som nation stadig synes at være "bundet" fuldstændig til dem. Vi var engang som en nation latterliggjort af en ungarsk født forfatter, George Mikes. Han er citeret for at sige \ "Continental mennesker har sex liv, den engelske have varmt vand flasker \", i sin morsomme bog med titlen "Hvordan skal en udlænding«. Det er muligt, at der var et element af sandhed i parodi, især i de dage, hvor design var kedelig og uinteressant. Disse er adjektiver, der sandsynligvis svarer til et typisk fastlandsklima billede af Anglo Saxon sex.
Men vent et øjeblik! Tingene har ændret sig. Jeg ville ikke have troet det, men disse ting er faktisk nu anses for at være "sexet"? Jeg fandt denne hjemmeside den anden dag, at bestandene stilarter og figurer, der er helt anderledes. Hvis jeg nogensinde var der søger efter en usædvanlig gave til at købe, særlige objekter der normalt ikke ses i butikkerne, ville dette sted være det sted begynde at kigge. De har alt her, fra en buddha statue til retro-telefoner, og de fleste ting i mellem!
For alle interesserede udelukkende i varmt vand flasker, var dem, der appellerede til mig polstrede formede produkter. Disse kiggede yderst komfortabel, og kan endda tilbyde stor terapeutisk værdi - især lider af ømme halse og lavere ryg. De er lavet af 100% genanvendeligt materiale, og er garanteret ikke at falme - perfekt til miljøbevidste.
fredag den 8. oktober 2010
GFS og dens udvikling
En fascinerende artikel, \ "GFS: Evolution på Fast-Forward \", i den seneste CACM bladet interviews Googler Sean Quinlan og udsætter de problemer, Google har haft med den legendariske Google File System, som virksomheden er vokset.
Nogle af de vigtigste uddrag: Beslutningen om at bygge den oprindelige GFS omkring [a] enkelt mester virkelig hjulpet at få noget ud af døren ... hurtigere .... [Men] problemer begyndt at ske ... går fra et par hundrede terabytes op til petabyte, og så op til tocifrede petabytes ... [Fordi] af mængden af metadata skibsføreren måtte opretholde.
[Også], når du har tusindvis af kunder alle taler med de samme master på samme tid ... den gennemsnitlige kunde ikke er i stand til at kommandere alle, at mange operationer per sekund. Der er applikationer såsom MapReduce, hvor du måske pludselig har en tusind opgaver, der hver ønsker at åbne en række filer. Naturligvis, ville det tage lang tid at håndtere alle disse anmodninger og master vil være under en hel del tvang.
64MB [var] den standard luns størrelse ... Da anvendelsen mix ændret sig over tid, men hvordan skulle vise sig at lade systemet klare effektivt med et stort antal filer [af] langt mindre end 64MB (tænke på Gmail, for eksempel). Problemet var ikke så meget med antallet af filer selv, men snarere med hukommelsen kræver alle disse [small] filer, som stilles på den centraliserede master .... Der er kun et begrænset antal filer, du kan rumme, før føreren løber tør for hukommelse.
Mange gange, det mest naturlige design for nogle ansøgning bare ikke ville passe ind i GFS - selvom ved første øjekast skulle man tro filen tælle ville være helt acceptabel, ville det vise sig at være et problem .... BigTable ... [Er] en mulig afhjælpning ... [Men] jeg vil sige, at de mennesker, der har brugt BigTable udelukkende til at beskæftige sig med fil-count problemet formentlig ikke har været frygtelig lykkelig.
GFS design model fra get-go var alt om at nå gennemløb, ikke om den ventetid, hvor det kan nås .... Generelt en hikke om rækkefølgen af et minut i løbet af en time lang batch job ikke rigtig dukker op. Hvis du arbejder på Gmail, imidlertid, og du forsøger at skrive en mutation, som repræsenterer nogle bruger handling, så sidder fast i et minut, reelt kommer til at rod dig op. Vi havde lignende problemer med vores mester failover. Oprindeligt GFS havde ingen mulighed for automatisk master fiasko. Det var en manuel proces ... Vores første [automatiserede] master-failover gennemførelse, der kræves på rækkefølgen af minutter .... Forsøger at opbygge en interaktiv database på toppen af et filsystem designet fra starten til at støtte mere batch-orienterede aktiviteter har bestemt vist sig at være en smerte punkt.
De grundlæggende forsøger at skjule, at latency, da de kender systemet nedenunder er egentlig ikke så stor. De fyre, der er bygget Gmail gik til en multihomed model, så hvis en instans af din Gmail-konto fik fast, ville du dybest set bare flyttet til et andet datacenter ... Denne evne var nødvendigt ... [Begge] for at sikre tilgængeligheden ... [Og] for at skjule GFS [latenstid] problemer.
Modellen i GFS er, at klienten bare fortsætter med at skubbe skrive indtil det lykkes. Hvis kunden ender ned midt i en operation, er ting tilbage i lidt af en ubestemt tilstand ... RecordAppend giver ikke nogen replay beskyttelse enten. Du kan ende med at få de data, der flere gange i en fil. Der var endda situationer, hvor man kunne få data i en anden rækkefølge ... [Og derefter] opdage poster i forskellige rækkefølger afhængig af hvilken bidder du tilfældigvis være at læse ... På det tidspunkt, må det have virket som en god idé, men set i bakspejlet jeg tror enighed om, at det viste sig at være mere smertefuldt end det var værd. Det bare ikke indfri de forventninger, folk har af et filsystem, så de ender med at få overrasket. Så måtte de finde ud af arbejds-arounds.Interesting at se udsatte vorter af Google File System og Bigtable. Jeg husker, da læser Bigtable papir, der overraskede over, at det var lagdelt oven på GFS. De tidlige beslutninger om at anvende en fil designet system til logs og batchbehandling af træstammer som grundlag for Googles interaktive databaser synes at have forårsaget en masse smerte og løsninger gennem årene.
På et beslægtet emne, et nyligt papir ud af Google, \ "Brug en markedsøkonomi Der Compute ressourcer på tværs af Planet-dækkende klynger \" (PDF), ser på et andet problem Google er der, prioritere alle de MapReduce batch job hos Google og forsøger at maksimere udnyttelsen af deres klynge. Papiret beskriver kun en test af en lovende løsning, bortauktionerer klyngen tid til incent udviklere til at flytte deres arbejdspladser til ikke-myldretiden og uudnyttede beregne ressourcer, men stadig en interessant læse.
Nogle af de vigtigste uddrag: Beslutningen om at bygge den oprindelige GFS omkring [a] enkelt mester virkelig hjulpet at få noget ud af døren ... hurtigere .... [Men] problemer begyndt at ske ... går fra et par hundrede terabytes op til petabyte, og så op til tocifrede petabytes ... [Fordi] af mængden af metadata skibsføreren måtte opretholde.
[Også], når du har tusindvis af kunder alle taler med de samme master på samme tid ... den gennemsnitlige kunde ikke er i stand til at kommandere alle, at mange operationer per sekund. Der er applikationer såsom MapReduce, hvor du måske pludselig har en tusind opgaver, der hver ønsker at åbne en række filer. Naturligvis, ville det tage lang tid at håndtere alle disse anmodninger og master vil være under en hel del tvang.
64MB [var] den standard luns størrelse ... Da anvendelsen mix ændret sig over tid, men hvordan skulle vise sig at lade systemet klare effektivt med et stort antal filer [af] langt mindre end 64MB (tænke på Gmail, for eksempel). Problemet var ikke så meget med antallet af filer selv, men snarere med hukommelsen kræver alle disse [small] filer, som stilles på den centraliserede master .... Der er kun et begrænset antal filer, du kan rumme, før føreren løber tør for hukommelse.
Mange gange, det mest naturlige design for nogle ansøgning bare ikke ville passe ind i GFS - selvom ved første øjekast skulle man tro filen tælle ville være helt acceptabel, ville det vise sig at være et problem .... BigTable ... [Er] en mulig afhjælpning ... [Men] jeg vil sige, at de mennesker, der har brugt BigTable udelukkende til at beskæftige sig med fil-count problemet formentlig ikke har været frygtelig lykkelig.
GFS design model fra get-go var alt om at nå gennemløb, ikke om den ventetid, hvor det kan nås .... Generelt en hikke om rækkefølgen af et minut i løbet af en time lang batch job ikke rigtig dukker op. Hvis du arbejder på Gmail, imidlertid, og du forsøger at skrive en mutation, som repræsenterer nogle bruger handling, så sidder fast i et minut, reelt kommer til at rod dig op. Vi havde lignende problemer med vores mester failover. Oprindeligt GFS havde ingen mulighed for automatisk master fiasko. Det var en manuel proces ... Vores første [automatiserede] master-failover gennemførelse, der kræves på rækkefølgen af minutter .... Forsøger at opbygge en interaktiv database på toppen af et filsystem designet fra starten til at støtte mere batch-orienterede aktiviteter har bestemt vist sig at være en smerte punkt.
De grundlæggende forsøger at skjule, at latency, da de kender systemet nedenunder er egentlig ikke så stor. De fyre, der er bygget Gmail gik til en multihomed model, så hvis en instans af din Gmail-konto fik fast, ville du dybest set bare flyttet til et andet datacenter ... Denne evne var nødvendigt ... [Begge] for at sikre tilgængeligheden ... [Og] for at skjule GFS [latenstid] problemer.
Modellen i GFS er, at klienten bare fortsætter med at skubbe skrive indtil det lykkes. Hvis kunden ender ned midt i en operation, er ting tilbage i lidt af en ubestemt tilstand ... RecordAppend giver ikke nogen replay beskyttelse enten. Du kan ende med at få de data, der flere gange i en fil. Der var endda situationer, hvor man kunne få data i en anden rækkefølge ... [Og derefter] opdage poster i forskellige rækkefølger afhængig af hvilken bidder du tilfældigvis være at læse ... På det tidspunkt, må det have virket som en god idé, men set i bakspejlet jeg tror enighed om, at det viste sig at være mere smertefuldt end det var værd. Det bare ikke indfri de forventninger, folk har af et filsystem, så de ender med at få overrasket. Så måtte de finde ud af arbejds-arounds.Interesting at se udsatte vorter af Google File System og Bigtable. Jeg husker, da læser Bigtable papir, der overraskede over, at det var lagdelt oven på GFS. De tidlige beslutninger om at anvende en fil designet system til logs og batchbehandling af træstammer som grundlag for Googles interaktive databaser synes at have forårsaget en masse smerte og løsninger gennem årene.
På et beslægtet emne, et nyligt papir ud af Google, \ "Brug en markedsøkonomi Der Compute ressourcer på tværs af Planet-dækkende klynger \" (PDF), ser på et andet problem Google er der, prioritere alle de MapReduce batch job hos Google og forsøger at maksimere udnyttelsen af deres klynge. Papiret beskriver kun en test af en lovende løsning, bortauktionerer klyngen tid til incent udviklere til at flytte deres arbejdspladser til ikke-myldretiden og uudnyttede beregne ressourcer, men stadig en interessant læse.
tirsdag den 5. oktober 2010
Abonner på:
Opslag (Atom)