搜狗 logo:纪念泰坦尼克号航行100周年

6 views
Skip to first unread message

科学技术观察

unread,
Apr 16, 2012, 3:07:05 PM4/16/12
to zh-scit...@googlegroups.com

搜狗 logo:纪念泰坦尼克号航行100周年


搜狗 logo:纪念泰坦尼克号航行100周年

Posted: 16 Apr 2012 11:52 AM PDT


搜狗 logo:纪念泰坦尼克号航行100周年


搜狗 logo:纪念泰坦尼克号航行100周年

Posted: 16 Apr 2012 07:14 AM PDT

电影《泰坦尼克号》已成为永恒的经典。为纪念泰坦尼克号航行100周年,搜狗搜索从4月10日-4月15日连续6天在首页系列logo,叙述了泰坦尼克号从启航到沉默的过程,非常之用心。也算是sogou logo中的经典了。

4月10日
泰坦尼克号1

泰坦尼克号1

4月11日
泰坦尼克号1

泰坦尼克号1

4月12日
泰坦尼克号1

泰坦尼克号1

4月13日
泰坦尼克号1

泰坦尼克号1

4月14日
泰坦尼克号1

泰坦尼克号1

4月15日
泰坦尼克号1

泰坦尼克号1

泰坦尼克号背景介绍
格林尼治时间1912年4月10日,当时世界上最大的蒸汽客轮泰坦尼克号在英格兰南部港口城市南安普敦开始了其处女航。4月14日晚11点40分,泰坦尼克号在北大西洋撞上冰山,并于4月15日凌晨2点20分沉没,造成了历史上最为严重的一次航海事故。此时事故共造成1522人遇难,生还者为702人。
版权所有,转载时必须以链接的形式注明以下声明:
原载于 搜索引擎周边
链接地址 http://www.eryi.org/SearchEngines/sogo-logo-titanic.html
-----
关注我们的微博:新浪微博 腾讯微博
相关文章:
You are subscribed to email updates from 搜索引擎周边
To stop receiving these emails, you may unsubscribe now.
Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

程序员真的很懒

Posted: 16 Apr 2012 07:16 AM PDT


程序员真的很懒


程序员真的很懒

Posted: 15 Apr 2012 08:02 AM PDT

  可能除了哲学家以外,笔者认为程序员是最懒的一群人。他们的职业看起来又似乎有一定的劳动强度。

  想想看,生物学家要亲自做所有的实验…给数百只小白鼠注射药物不可能自动完成。医生必须给病人进行身体检查;教授每年都要教授同样的课程;建筑师从各个角度制定方案,并手工地将方案一笔一划绘制出来。

  让我们再来看看更为辛苦的一些职业,情况更糟。营销人员要不断重复地进行同样的产品宣传;理发师日复一日地做着同样的事情;收营员每天都以相同的方式对货物进行结算…工厂工人…

  你面前呈现出了一幅图片,世界上有很多这样的人,他们每一小时,每一天,每一年,有些甚至一辈子都在重复做着几乎相同的事情。 

  来看看程序员

  每当我们想连续两次做同样的事情时—我们会尝试想一个方法来自动完成此过程。每当你写的代码是完成同样的一件事时,你会开始寻找一个库;每当你启动一个类似的项目时,你会去寻找一个模板。

  程序员的生活就是致力于消除重复的工作。

程序员真的很懒

  将琐碎地任务从我们的工作流程中剔除,这能让每个人生活得更轻松。这里有一个经典的笑话,说一个程序员情愿用一周的时间来写一个拷贝脚本,也不愿意将相同的文件复制粘贴两次,尽管复制粘贴可能只需要两分钟。

  该死的,我们要遵循DRY(Don’t Repeat Yourself不要重复自己)的原则。这个原则的基本内容是宁愿创建一个令人费解的抽象类,也不要将不相同但非常相似的代码写两次。

  这当然会导致很多问题。

  一般的软件项目充满了在顶层抽象类上构建的抽象类,你慢慢地会不清楚这些顶层抽象类将如何工作。甚至你完全不知道其代码在做什么。”Dizzying but invisible depth“,涉及到这个问题时,你真的应该读读这篇短文。

  另一方面,懒惰本身已经证明了历史上许多科学和工程发展所带来的背后推动力。用有轮子的拖车运东西比人工搬运要轻松;用船在水中前行比游泳来得容易;甚至如果你他妈的想炸掉一座城市,你投掷一颗原子弹也比投掷几千个小炸弹来的容易。

  所以这也许并不是说程序员是懒惰的。也许真正懒惰地是工程师们。只是恰巧在这样一个历史时刻,程序员作为工程师中最鲜明的一类,总是将世界向更好更光明的未来推动。而其它大多数领域已经在某种程度上稳定下来,或者需要更长的时间去适应新的工具。

  这里有一个重要的问题要问:程序员天生就懒吗?聪明懒惰的人容易被编程工作吸引吗,或者这是一种社会效应?懒惰源于最好的编程实践?还是最好的编程实践源于懒惰呢?

   

  一个比较

  最近,我有机会将一个建筑专业学生的一天与一个计算机科学专业的学生(就像我自己)的一天进行比较。

  大多数的建筑系学生的生活充满了这样或那样劳动密集的任务,这些任务是她工作的一部分。在任何时候,她都有可能要对一些模型进行拼凑粘合,在AutoCAD中从50个不同的角度对同一个物体进行绘图,或者在其它3D建模软件中重复相同的事情…然后将这些图片导入到Photoshop中成为真正好看的图。

  这种事会接连不断的发生。我估计她花费在课程作业上的时间比她实际上课的时间多一倍还不止(事实上她说花了5倍还多)。更糟糕的是,更好的完成这些任务并不能真正加快完成任务的进程,这只是意味着你多知道了几个键盘快捷键,意味着下次画图时你可能会少犯几个错误。

  熟练和精通完全无法优化关键的部分。

  相比之下,当我不上课时,我通常都在做自己的项目。因为我可以,因为我有充足的时间。当有作业布置下来时,一般情况下,我都可以在几个小时内完成…即使是最关键最重要的项目,老师也很少给我们超过一周的时间来集中完成作业,最多两周。

  精通编码并不意味着你打字更快(与建筑专业中等同的能力不同)。它意味着想出的解决方案更容易实现,利用工具来达到事倍功半的效果,诸如此类。最终,通过互联网进行测试评判,而实现过程是最无关紧要的部分,因为每个人都会。如果你有一天的时间,你可以实现某些东西。如果你有更多的时间,你可以使这些东西实现得更漂亮,模块化更高,可重用性更强,等等。

  基本上你能够快速地实现眼前的任务,你工作中大部分时间都在致力于使你的任务完成得更加漂亮。但这对于你手头的任务来说其实并不重要,你这样做是因为你可以。

  甚至于当程序员对自己的优化工作都产生厌倦时,他们会立马转而去创建工具来完成优化工作。

  事情就这样周而复始地重复着。

  接下来的家伙会使用他创建的新工具,使实现过程变得更快,接着优化它直到他最终厌倦,然后创建了一个新的更好的工具。

   所以…是辛苦的工作?

  但回到我最初的观点,辛苦工作对程序员的生产效率存在多大的影响?对于那些每天辛苦工作13小时以上,以取得竞争优势的创业者来说,这又意味着什么?这是值得考虑的一种优势吗?

   

  辛苦的工作可能对程序员工作效率产生负面的影响。它掩盖了背后所做的优化工作“哦,我可以手动把它完成,这将只需要10分钟时间”(其实这需要20分钟)。下一次,一个相似的任务到来时,你可能需要再次手动把它完成,长此以往…

  最重要的是,辛勤地工作会使你变得很笨。许多研究表明,持续疲劳的状态会使你做出错误的决策,甚至过多的决策也会让你会出错误的决定(称为决策疲劳)。事情上,这可能是我们喜欢创建抽象类并使用它们的原因—让其它人做大多数的决策,这样我就可以只专注于关键的部分。

  但是,我仍然没弄懂,到底是懒惰的人更喜欢编程,还是编程使他们变得懒惰… 

  原文:Swizec Teller    编译:伯乐在线 – 肖翔

评论《程序员真的很懒》的内容...

相关文章:

统计
微博:新浪微博 - 腾讯微博 - 论坛
月光博客投稿信箱:williamlong.info(at)gmail.com
Created by William Long www.williamlong.info
You are subscribed to email updates from 月光博客
To stop receiving these emails, you may unsubscribe now.
Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

Chrome 版 Collusion 插件:让你知道在你浏览时都有谁在追踪你

Posted: 16 Apr 2012 01:43 AM PDT


Chrome 版 Collusion 插件:让你知道在你浏览时都有谁在追踪你


Chrome 版 Collusion 插件:让你知道在你浏览时都有谁在追踪你

Posted: 15 Apr 2012 09:49 AM PDT

你也许听说过 Firefox 版的 Collusion 插件,不过 Disconnect 的大神们最近又制作了 Chrome 版本的插件,同样可以让你在浏览的时候实时查看你浏览的网站正在如何追踪和传送有关你的数据。你可以随时拉开 Collusion 地图来查看哪些网站使用了追踪 cookies 并且还向谁发送了数据,全部都是实时的。

安装好后,Collusion 的运行方式和 Firefox 版的别无二致,不过追踪检测做的更好一点同时还做了一些更适合 Chrome 用户的界面优化。地图最开始是完全空白的。随着你的浏览,你可以看到那些你浏览的网站会出现在地图上,如果他们使用了追踪 cookies 的话,他们就会变成红色。将光标放在任何一个圆圈上,你就可以查看关于那个网站的更多信息,包括它是否是一个众所周知的追踪者。如果你已经安装了隐私扩展的话,你很可能会看到相对较少的圆圈。不过无论怎样,你都应该会看到许多相互连接的圆圈——特别是那些有广告的、连接到社交网站的、或者在其所有子站(比如谷奥和谷安)上追踪访客的网页。就如我们之前所说的一样,有些端点其实是完全无害的,比如说 Disqus,它在整个网站上对你进行追踪,这样你就能对文章发表评论。但是其他的一些就要小心对待了。这是一个能让你对自己的隐私进行评估的工具。

这个插件是由制作 Disconnect for Chrome 插件的同一团队制作的,他们还有其他例如 Facebook Disconnect、Google Disconnect 和 Twitter Disconnect 这些独立的插件,都是用来移除网页上恼人的社交按钮并屏蔽同社交网站整合功能的插件。如果你也担心自己的隐私问题,这款插件值得一试。

传送门: Collusion

Via lifehacker


© michaelize 发表于 谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2012. | 1 条评论 | 永久链接 | 关于谷奥 | 投稿/爆料
Post tags: Chrome, Chrome Extension

德国人民用上真正的 Gmail 已经指日可待

Posted: 15 Apr 2012 09:46 AM PDT

当Google于2005年在德国推出Gmail的时候,他们很快酒杯禁止使用这个名字来作为邮箱服务使用了,因为一个德国企业家Daniel Giersch已经在德国注册了G-mail这个商标,其号称是简写的Giersch Mail的意思,且他已经在2000年就开始使用这个名字的邮箱服务了,远比Gmail要早的多。

于是在德国要使用Gmail的话,都会被重定向到googlemail.com,logo也改做Google Mail。Google曾经试图进行上诉,但2007年欧洲内部市场协调局驳回了他们的请求。不过来自德国的GoogleWatchBlog报道,最近似乎峰回路转了,Gmail.de域名连同Gmail商标已经与4月13日被移交到了Google手里。

尽管我们不知道他们之间做了什么样的交易,不过2006年的时候Giersch曾经表示Google欲以25万美元买下Gmail在德国的商标使用权,不过显然双方在6年前没谈拢。目前双方都还没发布官方消息,不过看起来德国用户应该很快就可以将@googlemail.com的信箱迁移到@gmail.com了。

说句题外话,我去德国的时候都曾经惊异的发现自己Android手机里的Gmail应用居然自己悄无声息的就变成了Google Mail,就因为我连上了德国的网络。居然Google会想到利用网络位置自动修改Gmail应用的名字,想得够细的,不过Google对Android里已经安装的应用控制权看来非常之大啊……

Via TC


© musiXboy 发表于 谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2012. | 5 条评论 | 永久链接 | 关于谷奥 | 投稿/爆料
Post tags: Gmail, Google Mail, lawsuit

Doodle:德国画家威廉·布施诞辰 180 周年

Posted: 15 Apr 2012 09:32 AM PDT

图片URL:http://www.google.de/logos/2012/wilhelm_busch-2012-hp.jpg

威廉·佈施(Wilhelm Busch,1832年4月15日-1908年1月9日)是德國畫家詩人以及雕刻家,並而其帶有諷刺性的插畫故事聞名。生於鄰近漢諾威的維登薩赫。並先後在杜塞道夫安特衛普慕尼黑就讀機械工程藝術,之後他轉為繪畫諷刺畫。

他於1865年發表首個插圖故事《馬克斯和莫里茨》,並獲得很大的成功。《馬克斯和莫里茨》和他的其他插圖故事作品都被認為是現代連環漫畫的主要先驅之一。美國著名漫畫《Katzenjammer Kids》(中譯:《頑童班》或《搗蛋鬼》或《吵鬧的孩子們》)的靈感就是來自《馬克斯和莫里茨》。

此外,威廉·佈施也為他的插圖故事寫一些類似風格的詩。並他畫了超過1000幅油畫,但他並沒有於生前賣出這些畫。

1908年1月9日,威廉·佈施於Mechtshausen去世。

Via 维基百科


© musiXboy 发表于 谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2012. | 没有评论 | 永久链接 | 关于谷奥 | 投稿/爆料
Post tags: doodle

【快乐周末】梦回 BBS 时期的 Google 搜索

Posted: 15 Apr 2012 09:13 AM PDT

感谢读者 Zeray Rice 的提醒。

如果你从上个世纪就开始上网,那么肯定会对BBS这个东西很有感情(我说的是传统意义上的Bulletin Board Systems,而非现在变形过来的论坛)。一位怀旧开发者Norbert Landsteiner就利用Javascript和HTML技术制作了这么一个复古的BBS形式的Google搜索首页,具备"收起不错"和搜索功能,所有界面都由彩色的ASCII代码描绘。

可惜的是被广泛报道后,现在搜索得到的总是错误。

Via Engadget


© musiXboy 发表于 谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2012. | 1 条评论 | 永久链接 | 关于谷奥 | 投稿/爆料
Post tags: BBS, fun, Google Search

You are subscribed to email updates from 谷奥——探寻谷歌的奥秘
To stop receiving these emails, you may unsubscribe now.
Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

数据库大会百度Dbproxy中间层架构概述

Posted: 15 Apr 2012 03:28 PM PDT


数据库大会百度Dbproxy中间层架构概述


数据库大会百度Dbproxy中间层架构概述

Posted: 15 Apr 2012 01:37 AM PDT

百度爱好者(Baiduer.com.cn)消息 由IT168(ITPUB、IXPUB、ChinaUnix)主办的2012中国数据库技术大会(DTCC)于(以下简称大会)2012年4月13日~15日在北京永泰福朋喜来登大酒店隆重召开。大会将针对大数据架构设计、数据库安全、分布式数据库、商业智能、NoSQL、Hadoop等多个重点话题进行深入探讨。此次大会得到了全国数据库技术高手们的高度关注与支持,是当前象征最高技术水平的数据库工程师盛会。 目前业界正在面临最大的难题,面对的数据量在爆炸性的增长,用户对互联网服务提出了更多的要求,因此在背后的架构上都是很大的挑战。随着数据库流量和服务器数量增长,数据库集群面临很多的问题,如何实现应用程序和集群的解耦,降低运维成本?如何实现数据库服务的高可用?如何将并发控制前移,保护数据库系统?如何降低数据库开发的成本,用中间曾实现基本的技术,降低了开发成本。

百度高级DBA 数据库Topic技术负责人尹博学

本节课上,百度高级DBA 数据库Topic技术负责人尹博学给到场的开发者介绍了百度数据库中间层技术,主要包括百度数据库中间层的整体设计、主要功能模块的实现策略、性能方面;同时就百度数据库集群所面临的问题、从这些问题中抽象出的对数据库中间层的需求同大家进行深入的探讨。 百度运维部DBA组负责百度所有数据库服务管理工作,是百度服务核心数据的提供者和保障者,是维护服务稳定的核心力量;涵盖数据库设计、评审、SQL代码REVIEW;数据库核心组件及平台的规划、设计、开发工作;使百度的数据库更稳定、更高效、更易于管理。 所谓三层体系结构,是在客户端与数据库之间加入了一个中间层。三层体系不是指物理上的三层,不是简单地放置三台机器就是三层体系,三层是指逻辑上的三层,即使这三个层放置到一台机器上。三层体系结构的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过与中间层通讯建立连接,再经由中间层与数据库进行交互。 在三层结构中,数据计算与业务处理集中在中间层,只有中间层实现正式的进程和逻辑规则。数据库中间层的定义:屏蔽集群内部细节,MysQL集群读写分离,连接池,负载均衡,访问控制,可集群化的部署,运维关键要求:支持高并发和低延迟,对数据库应用透明。

百度数据库集群的三层架构

百度Dbproxy逻辑框架设计

由于目前现有网络的各个核心部分随着业务量的提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设备根本无法承担。在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求。 Dbproxy负载均衡策略:1基本算法是基于数据库当前连接数的。2新建连接选取集群中同类角色中"当前连接数/权重"最小的数据库。

Dbproxy支持并发设计

连接池是数据库开发中最重要的策略 数据库连接是一种关键的有限的昂贵的资源,这一点在多用户的网页应用程序中体现得尤为突出。对数据库连接的管理能显著影响到整个应用程序的伸缩性和健壮性,影响到程序的性能指标。数据库连接池正是针对这个问题提出来的。数据库连接池负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而再不是重新建立一个;释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。 主要用于以下方面: 1构建有与MysQL连接池,提升性能。 2、连接池有三级hash策略,保证取到的连接可以正确的使用,包括read/write,用户权限,连接属性,如client_found_rows等(include/mysql_com.h)。 百度在Dbproxy做了四个方面的开发工作 1配置信息热加载。 2支持连接多个数据库集群。 3、将自身压力信息准确的输出。 4流量控制,不至于压垮数据库。 Dbproxy对应用程序透明策略 1、MySQL clientserver protocol。 2、数据库(MysQL)某系统特性。 3、各种语言的MysQL API,各种MysQL的连接框架的特殊行为。 Dbproxy提高性能的策略 1. 减少延长。通过进程+状态机的模式,无锁,nonblock,网络操作都是就绪之后才能执行。对于大结果集的接收,采用了非连续接收的模式,减少其他链接的等待。 2. 提高 并发处理能力。支持多个dbproxy工作进程监听一个端口。

大数据的储存:百度HDFS集群的数据压缩

Posted: 15 Apr 2012 01:29 AM PDT

百度爱好者(Baiduer.com.cn)消息 2012年4月13日,由IT168(ITPUB、IXPUB、ChinaUnix)主办的2012中国数据库技术大会(DTCC)在北京隆重召开。大会第三天,百度基础架构部高级工程师孙桂林发表了主题为"百度HDFS集群的数据压缩"的演讲。 当前,数字信息急剧膨胀。根据IDC的研究结果,2011年创造的信息数量达到1800EB,每年产生的数字信息量还在以60%的速度高速增长,到2020年,全球每年产生的数字信息将达到35ZB。面对海量数据处理的需求,"大数据"这一新的概念应运而生。关于大数据的定义,目前还没有标准的说法。 Hadoop Distributed File System,简称HDFS,是一个分布式文件系统。HDFS有着高容错性(fault-tolerent)的特点,并且设计用来部署在低廉的(low-cost)硬件上。而且它提供高吞吐量(high throughput)来访问应用程序的数据,适合那些有着超大数据集(large data set)的应用程序。HDFS放宽了(relax)POSIX的要求(requirements)这样可以实现流的形式访问(streaming access)文件系统中的数据。HDFS开始是为开源的apache项目nutch的基础结构而创建,HDFS是hadoop项目的一部分,而hadoop又是lucene的一部分。 HDFS设计的针对对象主要适合流式访问的超大文件、在使用便宜的硬件搭建的集群上运行。HDFS中Block的大小默认是64M,小于块大小的的文件并不占据整个块的全部空间(一个块可能存有多个文件)。 在谈到为什么使用百度HDFS集群的数据压缩时,孙桂林表示,在存储上带来了灵活的可扩展性、高可用性、充分提高了存储空间利用率。 使用Blocks的好处: 1) 可以存储大文件,一个文件的大小可以大于任何一个单块硬盘的容量 2) 把存储单元抽象成块而不是文件,简化了存储子系统:简化了数据管理、取消元数据关注 3) 能很好适应数据复制,数据复制保证系统的容错和可用性。 HDFS提供了两种namenode的容错机制: 1) 备份存储持久化状态的文件系统元数据的文件 2) 提供secondary namenode。Secondary的主要角色是合并namespace image和edit log,防止edit log过大。但是secondary namenode的数据较master namenode的数据有所延迟,所有数据恢复以后肯定会有数据丢失。 一般来讲,冷数据和老数据经常会被压缩,块压缩相对于文件压缩的优势在于三方面。第一,透明性,客户端不需要知道压缩的存在,也不需要知道升级。第二,灵活性,对实际压缩的算法没有限制。第三,本地性,不需要在跨数据节点的压缩操作。 百度HDFS集群的数据压缩 提到异步压缩时,孙桂林表示,一个集群能从未压缩的状态变成压缩状态最多花费十天,如果压缩的数据很繁琐,我们可以通过处理器来减轻CPU的负载。 存储压缩的机制 DataNode数据已经压缩了,Client可能不知道,DataNode 在响应Client的时候回将数据解压。 Client 和DataNode之间可以通过压缩的机制。整个通信协议需要一些扩展,需要告诉写方,我们所需要压缩的文件格式以及什么样的编码。在写的操作上,存储编码和传输编码不一样,我们可以选择是否压缩储存和传输编码。在读的操作上,支持一些协议来进行转换。 为了节省带宽,我们尽量避免DataNode 和DataNode之间重复压缩的问题。在Append之前我们需要解压最后的块,还是解压最后一兆数据。一旦文件被Append之后,表示这个文件的最后一个块不被压缩。在压缩的时候,首先我们需要选择压缩速率,相对而言解压的速度更为关键。我们的目标是要实现节省存储空间、避免压缩影响计算作业,实时压缩透明。 如何处理小文件 1、 把小文件变成大文件(归档操作) 2、 把相同目录下的小文件合成一个大文件。数据块的大小可以达到一个数量级,可以做压缩处理。 不同的集群,压缩比部太一样,压缩比介于10%到50%之间,大部分的集群我们都可以获取50%以上的空间收益。 未来,我们主推的是后台异步压缩,等待CPU空闲的时候,我们才会开始压缩。压缩过程和压缩编码完全透明,我们可以采用分级压缩方法。对于冷数据,我们可以使用一些极致的压缩算法,尽量来节省空间。通过一些归档操作,我们可以节省大量的磁盘空间。 很多时候,我们A模块的输出数据刚好是B模块的输入,我们可以提供一个块共享的Quota Calculating ,我们可以通过块共享的机制使用快速拷贝。 一个文件如果存在的时候,对于一些重复的块文件该怎么处理,这将是我们未来的发展方向。
You are subscribed to email updates from 百度爱好者
To stop receiving these emails, you may unsubscribe now.
Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610
You are subscribed to email updates from 科学技术观察
To stop receiving these emails, you may unsubscribe now.
Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610
Reply all
Reply to author
Forward
0 new messages