见闻

黄山

第一次自驾出行,第一次带着爸妈,拉着宝宝一同出行,也是第一次重装露营。

呈坎

徽派村落的代表无疑是宏村。不过不管是宏村还是呈坎现在去的都不是季节。之所以去呈坎完全是因为顺路,看地图呈坎就在去黄山的路上,而且在高速边上。

人文的景点更多看的是文化及历史,就如我当初看《人间词话》时也曾对文中的白石很感兴趣,甚至想去探访白石在杭州所留下的痕迹。我终归不是一个文化人,少了对文化及历史的好奇后呈坎只是一个普通的小村落。

论名气,呈坎完全无法同宏村西递相媲美,因此商业化程度也好低很多。里面的村民对游客都有些过于热情,这个热情多半来源于经济目的,他们的讲解收费是10¥。作为非文化人,对村子背后的故事并无多少兴趣,反倒觉得有些打扰自己游玩的兴致。

呈坎

汤口

黄山脚下的小镇。
想09年第一次来黄山的时候,大巴把我放到一个鸟不拉屎的地方,旁边只有一个不起眼的小店。当时我都怀疑是否是司机把我放错了地方。短短的几年,汤口已经变得有些过于繁华了,这次都开始堵车了。
黄山作为一个固定的景点,接待能力终归有限,能拓展的周边也极为有限。简单的说整个旅游市场的规模也只能这么大,能开发的潜力极为有限。汤口依托黄山发展起来,不知能走多远。

DSC06641

黄山

黄山本身并无太多变化,和第一次见时一样美,但人多。这次的时间并不是周末,虽受免票的影响人会多些,但有些太多。到处都是排队,连天都峰都排队。
至少近期几年是不会再去黄山了,黄山虽美,但人多到有些影响体验了。

DSC06694

露营

帐篷、睡袋、背包都已经买了很久了,一直几乎着要去露营却一直没机会。这次也算是作死,带着一大家子,抱个宝宝,背个大包去黄山露营。本还想继续做死背包徒步上山,老婆不同意才改为索道。没有爬山,外加一路排队,虽是重装但并未感觉太累。

DSC06707

编程

OA平台技术分享

为公司其他部门做的技术分享,在一定程度上也算是在公司内部推广Python。不过很不幸的是由于某些原因,该分享不幸夭折。

PPT在这里:http://vik.haoluobo.com/static/slide/oa/

下面是更为详细的文案。

OA平台概况

  • Nginx
    • 使用Nginx作为前端服务器,负责静态资源处理及HTTP请求分发
    • 在需要扩展到多服务器时,Nginx可以用做负载均衡服务器
  • UCenter(统一认证中心)
    • 统一的用户登陆管理
    • 用户信息存储在公司的AD域中
  • OA
    • 业务平台,公司的行政、人力等各项OA业务都在该平台搭建
    • 同携程、inTrack平台对接实现相关业务
    • 数据的汇总及分析

OA构架

  • 基于Django搭建的可插拔APP平台
    • 核心APP(基础APP)
      • 核心APP包括:UI框架、权限认证、流程引擎、用户、员工、部门管理等
      • 作为系统的核心模块,需要被其他各个业务模块所用到。
      • 为具体业务做支撑,大多不同具体业务相关
      • 核心模块在系统上线后将不太做改动,只需要少量的核心开发人员维护即可
      • 核心模块也是可复用的
        • UCenter同OA就是公用的相同的UI框架
    • 可插拔APP(业务APP)
      • 可插拔APP包括:人力模,请假出差、财务模块,报销、预算、行政、固定资产管理…
      • 同具体业务相关,依赖核心模块。
      • 业务需求多,且易变,在平台建设初期难以做周全的计划。
      • 各个业务模块相对独立,各业务模块可独立开发。
      • 多个业务模块可由多人并行开发。

Django

  • The web framework for perfectionists with deadlines.
  • 全功能的Web开发框架,依托Python提供快速开发的支持
    – 提供模板、控制器、URL路由、表单、验证、ORM等各项Web开发需要的基础功能
    – ORM及其强大,即使不懂SQL也可使用。
    – 支持数据库的版本管理,并可自动更新线上数据库结构
    – 模板支持继承清晰易用,对前后端分离提供很好的支持。

    • 成熟的社区环境,大量现成的APP可用
    • 被广泛应用,有成功易用范例:Instagram、OpenStack

流程引擎

  • 采用Python自主开发
  • 编码同配置结合在确保使用便携性的同时确保的功能的强大
    • 表单、业务处理逻辑编码实现
      • 数据模型通常变动不大,采用配置方式实现不但实现复杂,也不会能为开发维护带来多少便利
      • 流程常用的,同意、驳回、打回、撤销等基础操作流程引擎已自动实现,不需要额外开发。
      • 如在流程流转需要进行特殊操作,需用代码给出对应的实现。
        • 比如新员工入职流程结束后需要自动在系统中创建员工账号等
      • 配合代码生成器的使用,对于标准流程编码工作流程只需要完成数据模型的设计即可。
    • 流程流转用配置实现
      • 流程的审批节点,审批人变动概率较大,采用编码方式实现既不方便又不灵活
      • 流程流转的功能需要比较清晰,使用配置方式即可比较好的满足需求
        • 流转方式:抢先,会签
        • 流程节点的审批人、周知人、权限分享。
        • 流程分支支持
    • OA上所有流程都基于流程引擎开发
  • 提供代码生成工具生成流程框架
    • 对于简单的流程,只需要实现数据模型即可生成完整的业务代码

Why

  • Why

    • Python

      • Python is powerful… and fast;
        • 这里的快更多的是开发速度快。语法丰富,简洁
        • 开发效率高是我们选择Python的一个重要原因。
          • 信息部就2人,需要负责需求整理、设计、开发、测试所有工作,对开发效率要求非常高。
        • 不需要编译,启动时间快节约开发时间
          • 一个大Java项目编译要超过一分钟,Web服务器启动又会超过一分钟
          • OA对比原有的KM。KM启动时间超过1分钟,OA可在5秒内完成重启。
        • Python本身并不慢,
        • 真正影响性能的代码所占总代码的比重很少。
          • Python可方便的同C集成,用C扩展性能
          • 注:使用Cython可直接在Python里写C代码以提高性能
          • 目前不少性能敏感的库都采用C扩展的方式进行加速,方案成熟
      • plays well with others;
        • 对C友好,使用ctypes可直接使用C接口的动态库
        • 很多软件都有提供Python接口。如:OpenCV、MATLAB
      • runs everywhere;
        • 支持几乎所有的操作系统(包括各类嵌入式系统)
      • is friendly & easy to learn;
        • 非常容易入门。对有经验的开发者,花一天时间熟悉语法就可直接使用
      • is Open.
      • Python的第三方资源足够丰富,应用也足够广泛
        • 有很多采用Python的成功应用
          • OpenStack、Dropbox、Youtube、Mercurial
        • 虽然比不上Java,但Python的资源也非常丰富。
          • Django(Web)、Cython(在Python中直接写C)、NumPy(可选计算)、PyQT(UI)、QPython(Python on Android)
      • Python无所不能,但并不适合做所有事情。比如Android移动端的开发还是用Java更合适

      • 开发效率高

        • 信息部人少,需要快速实现需求
        • Java严谨、Java有接口等概念,在大项目协作时更容易。但由此带来的开销是在小团队情况下开发效率更低。
    • Django
  • Why Not
    • Java
      • Java严谨、Java有接口等概念,在大项目协作时更容易。但由此带来的开销是在小团队情况下开发效率更低。
      • 信息部是个小团,Java带来的好处不如优点大。
      • 即使是一个大团队,也可通过模块化的方式来减少规模化带来的沟通开销。除阿里这样的超大公司外,很多时候Java都不是一个很好的选择。
      • Java在Web开发方面一直是由多个开源项目所推动,本身就缺乏一个很好的体系。
        • Java的各个开源项目独立发展,在开发初期并未仔细考虑过如何同其他项目协作。
        • Java主流实现都是围绕如何实现一个超大规模项目来设计,对小项目来说负担太重。
        • 使用Java实现一个非常小的功能也需要写大量的代码及超多的XML配置。现阶段Java开发已经简化很多,但相比Python依旧太过繁琐。
    • Node.js
      • 近年来前端技术发展非常迅速。
      • 前端开发只能用JS,因此会JS的群体非常广泛。
      • Chrome V8,Node.js将JS引入服务端,收到广大前端爱好者的支持,迅速发展。
      • Node.js天生异步,有着不错的性能。
      • 使用callback实现异步,大量的callback导致代码不容易理解。
    • redis(Cache)
      • 开发应当优先考虑功能的稳定性,然后才是性能问题。
      • 性能问题更多的是构架问题,应当优先优化构架。
      • 以我们公司的规模还远没到需要增加缓存的情况。
      • 缓存会增加系统复杂度,也可能带来一定的潜在风险。

前端技术构架

  • UI
    • AdminLTE(Bootstrap)
      • 信息部人少,缺少专业的UI及前端人员,尽可能的利用现有可用的资源。
      • AdminLTE是一套基础Bootstrap的界面框架,提供了大量基础的界面功能。
      • Bootstrap是当前非常流行的前端框架,有着丰富的资源。
  • JS
    • 使用Bower管理静态资源。
      • 静态资源的包管理工具
      • 方便静态资源的升级管理
      • 避免将静态资源直接复制到代码库,为代码库增加存储以及响应压力
    • JQuery
      • JS事实上的标准库,可极大的加速JS开发。
    • formset.js、datepicker等
      • 实现formset,日期选择等节目效果。
    • 使用Django-Compressor进行静态资源的压缩优化。
  • Why Not
    • Webpack
      • 近几年前端发展速度非常快,前端开始变的复杂。JS不仅仅是为Web页面锦上添花。为配合使用JS进行大规模项目的开发,需要相关工具进行配合。
      • 前端打包工具,可对JS库进行依赖管理,控制JS包的按需加载。可对JS/CSS编译(ES6/TypeScript/SCSS/LESS),压缩,图片优化等
      • OA前端应用相对比较简单,Django-Compressor可以满足要求现阶段需求。相比Webpack能带来的好处,没必要为项目增加不必要的复杂度。
    • React
      • 用来构建用户界面的 JavaScript 库
      • 更适合单页面的应用,如为手机提供类似APP的体验。
      • 不采用原因同Webpack一样。
未分类

LBForum后续计划

开源应当是一件很认真的事。

  • 保证持续的维护与更新,保证该项目的活力。
  • 有完善的测试用例,方便在添加功能以及merge其他人的改动后进行功能测试。保证软件的质量。
  • 完善的文档,让初次接触该项目的人可以快速的知道如何使用。

我写的一些东西基本上都是出于个人兴趣,因此有些随性,兴趣来了就写一写,兴趣过了这个项目就荒废了。
LBForum曾一度荒废,近期由于集成到公司系统,顺道做了一些更新。接下来可能还会陆陆续续做些更新。

  • 增加Python3的支持
    • 单纯的增加Python3的支持并不难。由于我的测试用例并不完善,增加Python3后测试的工作量会增加,因此一直没有做。
    • 注:现在以及可以支持Python3了。比预计的要顺利不少,只做了很少的改动就完成了Python3的支持。
  • 增加Rest接口
    • 之前的Rest接口一直都是手动实现而且也还挺方便,想试试Django REST Framework看能减少多少工作量。
  • iOS的论坛APP
    • 一直想做个移动APP,刚好用论坛来尝试一下。
    • 第一个版本应当只有浏览功能,登陆、回帖、发帖等功能将在日后逐步添加。
编程

React

之前简单的对比过React和Vue.js。React组件化程度很高,粒度很细,“模板”分散在整个JS文件中。Vue.js模板和JS文件分离,看上去要清晰不少。当时比较倾向于Vue.js。
近期又去了解了一下两个框架。Vue.js居然也计划要支持JSX了,模板和JS分离这本是我偏好Vue.js的一个重要原因。此外就网上的评价来看Vue.js的坑也并不比React少。考虑到React的背景,以及周边成熟的生态环境,决定再给React一个机会。
把React的《QUICK START》完整的看了一遍。React的入门并不难。如果不想将系统改造成“单页面应用”,只将页面上部分功能组件化也不存在困难。React的粒度很细,但拆分完后各部分会比较简单。
按照React的说法,React会颠覆大家对传统Web开发的认知,但一旦熟悉就会发现这很棒。
React是否真的很棒?因为没真正用过,还不敢断言。但React的组件化思想还是有些意思,本身的概念也比较清晰,加上并不复杂,或许值得一试。

vicalloy的庄家

LBForum更新Django1.10支持

前一段时间公司需要上线一个论坛系统。公司系统采用Django开发,因此考虑集成一个论坛的App,另外出于一部分私心,最终采用了LBForum
之前LBForum很久没有维护,很多依赖包的版本已经不对,导致已无法正常运行。这次更新修正了之前的一些bug,另外对依赖进行更新。现有的依赖包都明确指定版本,避免因依赖包更新导致无法运行。

这次升级后对演示站点同步进行了更新,演示站点地址: http://lbf.haoluobo.com/

LBForum的主要更新

  • Django更新到1.10
    • 目前只测试了1.10,不确定在其他版本下是否可以正常运行
  • 出于工作量的考虑,只保留v2ex主题,不再提供FluxBB主题的支持
    • 如果你想使用FluxBB主题,可切换到v1.0分支,里面有老代码
  • 去掉django-simple-avatar,使用easy_thumbnails提供用户头像支持
  • django-helper、django-lb-attachments使用django-lbattachmentdjango-lbutils进行替代
    • 前面的两个包是我很早之前维护的工具组件,现在已不再维护。后面的是现在新维护的工具组件
  • 去掉django-onlineuser
    • 这个用户在线模块一直有些问题,在想好怎么优化前暂不增加在线用户统计功能
  • 使用django-el-pagination替代django-pagination
    • django-pagination已经近乎不维护的状态,django-el-pagination在功能以及活跃度方面都要更好一些
  • 去掉South
    • Django自带的数据库结构维护已经很成熟了
  • 使用bower管理第三方JS库
    • 使用bower,避免将大量的第三方库直接塞到代码库中。
  • 上传组件替换为jQuery-File-Upload
    • 之前的上传组件依赖Flash。在Flash越来越不流行的今天,依赖Flash不再是一个好选择。
  • 使用MediaElement增加视频支持
  • 使用Pygments提供语法高亮支持
    • 在安装Pygments后,可对代码进行语法高亮

lbforum-site的主要更新

对应的演示站点也做了相应的更新。

  • LBForumdjango-lbattachmentdjango-lbutils使用Submodule的方式导入
    • 相比采用pip方式安装,使用Submodule的方式对子模块的更新和修改起来要方便的多。
  • 使用django-allauth替代django-registration
    • django-registration老早就不再维护了。django-allauth在功能以及活跃度上都还不错。
  • 针对注册,加了一个简单的校验
    • 网络上的垃圾爬虫无处不在,之前的演示站点已成了垃圾广告的集散地。这次在注册的时候加了一个简单的校验,必须在captcha内填写captcha才可正常注册。因为刚更新,还不知道效果如何。注:现在的爬虫似乎很智能了,这个功能似乎并不太有效,还是不定期会有爬虫上去发帖。

其他一些问题

  • 一直想把文档给整“好看”一些。不过写文档并不是一件轻松的事情,面对懒癌文档的事情只能继续挂起。
  • 目前主流的Python库已经都支持Python3了,增加Python3算是挺有必要的一个工作。根据之前Python3支持的经验,要同时支持Python2和Python3还是得花费一些时间。由于我主要还是用Python2,因此也先挂起了。
编程

目前项目用的一些东西

项目基于Django构建,如果你们也在用Django,可以参考下。

源代码管理 HG

之所以用HG完全是因为公司代码库用的是HG,如果让我选当然更愿意用Git。大多情况下HG也已经够用了。
项目中开发的Python公共模块使用submodule的方式引入。采用submodule的方式对子模块的更改和更新都会比较方便。

JS等静态资源管理 Bower

作为一个Web项目自然少不了用到jQuery等第三方JS库。将这些第三方库全部下回来丢到代码库里一是让代码库变的不必要的臃肿,另一方面库之间的依赖关系也不容易管理。引入Bower后代码库要干净很多。

Web前端框架 Bootstrap

现在用Bootstrap的网站有些太多了,以至于Bootstrap让人有些审美疲劳,不过对于缺少专业前端的团队来说Bootstrap绝对是个利器。

JS/CSS压缩 django-compressor

使用django-compressor可以对JS/CSS进行压缩,加快网站加载速度。

表单 crispy_forms

如果是做互联网应用crispy_forms的作用可能不大,但是对管理后台来说crispy_forms非常棒。

django-impersonate

让你可以方便的切换成其他用户。在系统维护的时候会方便很多。

异常日志 Sentry

Sentry 是一个实时的事件日志和聚合平台,基于 Django 构建。Sentry可以将程序的所有异常自动记录下来,然后在一个好用的 UI 上呈现和搜索。如果你还没用过Sentry,强烈推荐一定要试试。

为什么没有用

  • React/Angular
    • 我们的应用场景还是传统的WEB应用,React/Angular可能更适合Web APP的场景,应用起来可能不能带来太多的便利性。
  • Webpack
    • Webpack 是当下最热门的前端资源模块化管理和打包工具。也曾想试试,不过我们这里前端部分还不算太复杂,冒然引入Webpack似乎也不是太必要。目前Bower+django-compressor已可以较好的满足我们的需求了。
编程

Swift

最近在看Swift。已经很久没有这么“悠闲”的看一本书了,从头开始认真的看一本书的感觉还不错。
Swift给我的感觉是一门挺“特别”的编程语言。Swift是一门动态语言却加入了很多静态语言的特性,从一定程度上说Swift比很多静态语言还更严谨。

  • 在Swift里所有数据都是有类型。Swift有着强大的“类型推导”,因此很多地方是不需要指定数据类型的。也正是因为所有数据都有类型,相比大多脚本语言,编译器能检查出更多的问题,IDE的自动化程度也很高。
  • Swift和Objective-C采用ARC进行垃圾回收。以极低的性能损耗换取了接近全自动垃圾回收的便捷性。(注:官方宣称Swift比Objective-C要快很多)
  • Swift有这众多的动态特性以及语法糖,使用便捷且功能强大。

Swift中的?以及!

之前在其他语言中没有见过类似语法,初次接触时非常困惑。但一旦理解了之后就会发现这其实非常简单。
String?表示String或nil。首先要理解 String? 同 String 并不是同一个类型。 ?是一个封包的操作符号,将String封装成 ? 类型。(注:有点类似泛型,按照泛型的写法是 ?<String>
!则是解包操作,将String?转换为String。如果被解包的数据是nil,则会解包失败抛出异常。

Swift中的Dictionary以及NSDictionary

Swift中的Dictionary同NSDictionary可以通用(NSArray类似),但实际上它们并不是同一个东西。它们在混用的时候,编译器是需要对数据进行转换的。如果你代码中涉及大量的Dictionary/NSDictionary转换,很可能导致你的代码出现性能问题。(注:据说Swift中JSON处理速度慢就是该问题引起的)

编程

django-lbutils

在Github上公开了不少项目,不过其中大多都算不上“开源”。在我看来开源也应当是一件认真的事情,需要对项目持续的维护,同时也需要提供必要测试用例及文档以保证项目的质量。
最近打算将自用的Django工具组件做个简单的整理然后发布了。为了让项目不要太“随意”,开始补测试用例及文档。因为是自用,测试用例和文档几乎为零。最初只是想简单的修葺,不想真正做起来工作比预期的要高出很多。整了许久代码中的注释依旧很不全,测试的覆盖率都还未达到80%,文档更是没开始动。因为文档还没弄完,所以项目也不算正式发布,如果你感兴趣可以先去看看django-lbutils
为了这个项目,尝试了一些之前经常看到却一直没怎么使用过的工具。

Tox

Tox是一个Python的自动打包测试用具,用来测试Python库在不同环境下的兼容性。因为是自用,本机环境跑起来是没啥问题。不过在兼容性测试时部分测试用例在Python3以及Django的某些版本下跑起来会有问题。为了搞定兼容性花费了不少时间。

Travis CI

Travis CI是一个在线的持续构建平台。Travis CI会检查你在Github上项目的变化,每当有新push的时候进行自动编译。我现在是每次改动后,直接在Travis CI看测试用例的执行情况。

Coveralls

Coveralls测试覆盖率查看工具。结合Travis CI,可在每次测试完成后将测试覆盖率信息推送到Coveralls。在Coveralls可方便查看当前的测试覆盖率。

Read the Docs

Read the Docs文档托管服务。可从Github抓取文档并自动编译好生成在线文档,目前几乎所有的Python库都将文档托管在上面。

无责任乱评

畸形的中国房价

年后,有是一轮房价的快速上涨。上海、北京城区的房价轻松破5万每平米,北京更是创造了“11平学区房卖530万”的天价。在我看来现在中国的房价真是贵,贵的离谱,这时候如果想买房投资绝不会是一个很好的选择。

相比房租,房价高的离谱

近年来银行利率一降再降,但也保持在5%左右。如果你贷款120w买房,这意味着你每年单银行利息就得支付6万,平均每月还贷5000。在中国的1~2线城市里,120万装修好的房子顶多也就能租到3000。如果不考虑房价上涨,每月投资收益就损失40%(这还不考虑租房的空窗期)。
再参考一下国外的房价和房租。日本人口密度很大,寸土寸金,国人印象中日本房价一直居高不下。日本房价可以参考知乎的问题日本房产是否比北京上海便宜?具体原因是什么?。从里面可以看到,中国北京、上海的房价已经成功赶超东京。另外从东京和北京、上海在物价上差别有多大?这个文章里可以大致了解到东京租房价格。“家住千叶县市川市靠近浦安 距离东京都心地铁半小时左右 房租5万4 不到20平米”换算成人民币和国内的房租面积算法,也就是30平米不到,3000千的房租。大致推算下来,房价相当的情况下,日本的房租比国内的房租要贵到近一倍。
注:日本的房子面积不算公摊,因此房子面积相比国内要乘以个1.4左右。日本尽力过房价的暴涨以及崩盘(理性房价的回归),对国内的房价走势有一定的参考价值。如果真有100万现金,可以购买银行的信托基金,通常收益回报率是可以大于房贷利率的。

中国的房价为什么如此的贵?

一般大家都在说房价贵,一边又都在买房。你说房价高,却又一山更比一山高。中国的房价贵,自然有贵的理由。

买房实际上是在做风险投资
既然短期内无法通过房租获利,那就只能寄希望于房租或房价的上涨了。按照现在的租金情况,租金至少要上涨一倍才有希望获利。按照中国目前的薪资水平,如果房租真上涨一倍,立马很多人无家可归。想要实现房租的翻番需要漫长的等待。既然考租金获利不靠谱,最直接的就只能是房价上涨后赚差价了。目前的房租收益已到了一个非常糟糕的情况,如果房价继续快速上涨,房租收益情况必然更加恶化。既然买房如此的不“合算”为何还要买房?房租虽然无法决定房价,却又不可避免的会影响房价。
从经济的角度来讲,不管是房租的上涨还是房价的上涨都需要靠国家经济的快速增长为前提。投资房地产实际上是投资“国家”这个“创业公司”,预期国家在今后可以继续的快速增长。

国人“有钱”
中国的独生子女制度,让一个房有机会耗干两个家庭的所有积蓄。同时又是独生子女制度让大家能接受花干了所有积蓄也只能买89方的小户型的现实。

租房的困境
从经济的角度讲现在买房很不合算,但如果你真不买房问题不少。
不规范的租房市场
租房虽然省钱,但并不省心。在中国你想安心的长期租住并不容易。由于房租不赚钱,房东大多想着等房价涨了卖出去赚一笔。租房意味着你随时都可能被房东扫地出门被迫搬家。

资源(尤其是教育)的不平衡
如果没有房,孩子上学都是个问题。

今后

简单的说我并不认为中国房价可以持续的快速涨下去。中国的房地产有着太多的问题,太过脆弱,犹如美丽的肥皂泡,一不小心就会被戳破。但我也并不认为房价会崩盘。中国经济及房价的发展轨迹像日本,但中国不是日本。日本崩盘了,中国未必。中国ZF更不市场,有着更大的调控能力。

房价稳中有升
高存量,房租不赚钱,房价不涨,难免会引发一定量的抛售,搞不好就真崩盘了。因此我觉得房价稳中有升,即给买家一些希望(大多已经买房的人都希望涨),又不至于让房价相比租金继续太过畸形。
当然,这是我说的理想情况,就实际情况来说房价下跌的压力可能比预期的还要大。
注:“快速平稳”的降低房价的手段之一是“货币贬值”。现在的中国早已不是上世纪90年度的中国,中国的经济体量在这里,一旦主动大幅度货币贬值很可能是灾难性的。

中国经济的不确定因素-人口红利
然后就如国家自己说的一样“中国的经济到了拐点”,中国传统粗放型的增长难以继续支持中国的快速发展。然而转型又岂是如此的容易。
中国的经济增长想来都是靠资源推动,其中最重要的一个资源就是“人力”。长期以来中国有着丰富的人口红利,中国的人口红利在近几年就将达到高峰,再之后就要开始衰减了。随着人力红利的到期,中国能否继续高速增长就更依靠“产业升级”,但中国所谓的“产业升级”似乎走的并不顺。
人口增速的降低带来的另一个问题是住房需求降低,需求的降低也必将对房价产生不利的影响。中国目前人口迁移的形式是逐步向各大中城市迁移。现在不少农村几乎已成了空村。可以预见,中国的一二三线城市的人口还将继续增加,但增速会有一定程度的减慢。四线城市以及乡镇的人口甚至会有一定的减少。

人口政策的转变
中国近期全面开放了2孩,不管大家愿不愿生,多生孩子多种树都今后的主旋律。一旦2孩,之前的小户型必然无法满足居住需求。相对而言,人们对房价单价的承受能力就变弱了。之前的一套房已经将很多家庭的家底掏空(贷款都没还完),这时在面对几个孩子的情况时必然无法同现在一样给孩子如此大的支持力度。

城市发展模式的转变
中国长久以来都是城市的巨型化。随着信息技术的发展,让城市的中心优势变的不再明显。或许今后中国的城市会逐步走向“泛中心化”,大量的公司移到郊区,除了周末逛街,大家不用都挤到中心城区。城市范围扩大后,土地的紧缺的可得到一定程度的缓解。

最后

中国房子只有70年产权-_-!

未分类

眼镜验光配镜须知

每次换眼镜都要配坏好几幅眼镜,这次在配坏了两副眼镜后决定自己去买了验光眼镜来对度数进行微调。
既然决定要自己验光,有些验光常识还是需要知道的。

矫正视力到多少合适

通常大家都会希望矫正视力越清晰越好,但对于近视的患者来说如果“过矫”会导致看近处的时候眼镜更容易疲劳。现在大家成天都盯着电脑手机,因此矫正视力到0.8~1.0就可以了。

正规的验光过程是怎么样的

知乎上的这个问题“一个完整的眼睛验光流程是怎样的?”里有详细的验光说明,大家可以去详细了解下。
下面把几个重要的步骤简单的说一下。这里列出的只是一些比较重要的步骤,如果连这些步骤都没有,那么这个验光流程是非常不正规的。

  • 测瞳距
  • 电脑验光
  • 散光轴位和度数初步检测 看一个放射图,调整到所有线都一样清楚
  • 红绿平衡 看红色及绿色背景的视标。如果绿色比红色清楚,说明过矫了。
  • 试戴调整度数 带验光用的插片眼镜最最终的度数调整。

自己验光

由于长期配镜,加上去眼镜店验过,对自己的度数基本了解,因此直接跳到最后一步,使用验光眼镜对眼镜度数进行微调。验光眼镜可以很容易的在淘宝上买到。
验光眼镜每侧可以插3个镜片,因此在购买插片的时候可以再买两片25度的插片用来做对比测试。眼镜上有两个旋钮,用来调整轴位。如果有散光,可以反复调整轴位直到确认最合适的轴位。

近期配镜体验

上一副眼镜在“亿超眼镜”配的,当初验光还算仔细,这次配镜还是找他们家。哪知他们对加盟店几乎没有任何管理,验光过程及不正规,最终拿到的眼镜非常不合适。之后去了“毛源昌”。毛源昌的验光流程比较正规,拿到的眼镜佩戴也还比较舒适,和自己通过反复试戴确认的度数基本一致,轴位方面有10~15度的差距。验光师没有考虑我长期使用电脑的实际情况,眼镜度数给的“太足”,实际使用中存在过矫。

镜片

镜架方面主要是舒适、好看,个人感觉贵的和便宜的差别不大。镜片方面需要关注的是镜片的折射率和阿贝数。阿贝数越高越好。折射率越高镜片越薄,但通常情况下阿贝数会越低。国外知名品牌的镜片价格相对昂贵,且假货多。除要求特别高,一些国产知名品牌的镜片也是个不错的选择。从网上看国产的里面“明月”、“万新”的镜片相对较好。

红绿视标
红绿视标2

散光放射图
fs

视力表
psd6615