普通和非普通住宅

普通住宅和非普通住宅定义区分 

1

普通住宅:是指按所在地一般民用住宅建筑标准建造的居住用房屋。目前,多为多层住宅和高层住宅。多层住宅是指2-6层(含6层)的楼房;高层住宅是指6层以上的楼房,高层住宅多安装电梯。普通住宅和非普通住宅的区别由于各地对多层和高层的定义不一致,划分标准各地可根据实际情况酌情确定。

2

普通标准住宅:是指按所在地一般民用住宅标准建造的居住用住宅。高级公寓、别墅、度假村等不属于普通标准住宅。普通标准住宅与其他住宅的具体划分界限,2005年5月31日以前由各省、自治区、直辖市人民政府规定。2005年6月1日起,普通标准住宅应同时满足:住宅小区建筑容积率在1.0以上;单套建筑面积在120平方米以下;实际成交价格低于同级别土地上住房平均交易价格l.2倍以下。 

3

非普通住宅:

1、住宅小区建筑容积率在1.0以下(不含1.0); (除高档别墅外,平常的居民楼一般都在1.0,这条基本可以不用考虑)

2、单套建筑面积在140平方米以上(含140平方米);(你买了套房子138平就是普通住宅,你要再买套141平的,这套就是非普通住宅)

3、实际成交价格高于该区市场指导价1.2倍以上(不含1.2倍);(有的地区有成交价规定,比如有地区规定本区域市场指导价为10000一平,而你买的房子合同单价是13000一平,这就是非普通住宅了。)

普通住宅和非普通住宅的区别以上三点只要符合一个,即为非普通住宅。 反之则为普通住宅。

普通住宅和非普通住宅税费区别 

1

  个人所得税:成交价*1%

1、普通住宅满5年(含5年),且为卖方家庭唯一住房,免征。

2、非住宅(无年限制)按成交价的1%征收。

3、转让受赠住房一律按差额的20%征收。

4、直系赠与,看老证,满5年免征。

2

  营业税:成交价*5.6%

1、普通住宅满5年(含5年)免征。

2、普通住宅未满5年,全额征收。

3、非普通住宅满5年,差额征收。

4、非普通住宅未满5年,全征

3

契税:1、成交价*1%,90平方米以下的普通住宅,若买方不是唯一住房的按成交价3%征收。

 2、成交价*1.5%,90平方米以上,144平方米以下普通住宅,若查实买方不是唯一住房的按成交价3%征收。

 3、成交价*3%,(144平米以上含144平米)

4

土地收益金:成交价*0.5%,房改房征收。

5

土地增值税:1、成交价*1%,普通住宅免征。

       2、非普通住宅,全征(无年限制)、 “增值额”*30%征收。

6

印花税:成交价*0.05%

1、普通住宅类,暂免。

2、赠与,非普通住宅,征收(双方各0.05%)。

7

转让手续费

1、面积*2.5元/平方米,已购公房(房改房、直管公房、安居房、经济适用房、集资建房)。

2、面积*6元/平方米,商品房。

3、面积*8元/平方米,别墅及非普通住宅

8

产权转移登记费

1、80元/本,普通住宅及配套车库

2、550元/本,非普通住宅及不配套车库。

3、10元/本,共有权证。

SOLID编程原则

​1.单一职责原则:每个类只负责完成一个职责,当它需要完成多个职责时就需要将它拆分开来。
2.开放封闭原则:对扩展开放,对修改封闭。
3.里氏替换原则:子类对象可以替换(代替)它的所有父类(超类)对象。
4.接口隔离原则:用多个专门的接口比使用单一的接口更好,类与类之间的依赖应该建立在最小的接口上。避免接口臃肿,污染。
5.依赖倒置原则:抽象不能依赖于具体(实现),具体应该依赖于抽象,对抽象进行编程,降低客户与具体实现模块间的耦合。高层模块不应该依赖于底层模块,都应该依赖于抽象。

牛人的六个能力

我前一段时间写过一篇文章《你通讯录里的不叫人脉,只能叫人名》。讲到人脉链接的话题,其实我们拓展人脉的时候,都希望结识一些比自己厉害的人,也就是我们所说的牛人。但是很多牛人往往就像电视里的偶像明星一样,以我们现在的高度是根本够不到的,那些人对我们来说,只可远观。

最近我在网上看到了一个世界500强HR识别牛人的理论,他用6个标准来判断这个人是不是一个有潜力的牛人,特别是用在公司人才培养和人员招聘上。互联网时代造成的扁平化,让很多草根,民间的牛人,有了更多成功的机会,我们身边可能就隐藏着各种牛人,所以在人脉拓展的时候,如何能够高效的识别牛人,还是非常有必要的。

1,元认知能力

“元认知”就是对于认知的认知,是对于自我认知过程的思考。是不是觉得第一个标准就把你镇住了,什么叫“元认知”?根本不理解啊。确实,我查了好久到底该如何用口语化来表达这个心理学名词,我结合了一些网上的解释,尝试着给你们做一个简单的描述,“元认知”就像是“学习如何学习”,学习的是学习的过程和方法。

比如你上学的时候可能会遇到过一些学习很好的学生,但是他们并没有天天开夜车,该玩玩,该谈恋爱谈恋爱,但成绩就是好。我高中的时候有一个比我小两届的学弟,他一直占据着年级第一的位置,但是这个人看起来是那种阳光大男孩,个子很高,经常打篮球,放学也基本是打铃就往校外冲的人,也不背书包,差不多每天就带一本书或者不带书。后来我毕业了,高考的时候听说好像是考上清华了。这样的学生其实更多是在用高效的学习方法学习,不死读书,做事,学习效率都很高。他们就是元认知能力很强的人。

2,思维跳跃能力

我们经常听到一个词叫“逻辑思维”,说明一个人的思考模式是确定的,前后有紧密联系的,而且是合乎自然规律的思维方式。思维能力很强的人他能够很好的掌握各个点之间的联系。这是一种高智商的表现,做事情可以根据需求进行不同的选择,不用按部就班的一步一步走。

思维跳跃能力强的人,比较不容易钻牛角尖,灵活多变,当遇到阻碍的时候,能够快速的跳开,对事物能够进行多维度,多角度的思考,对于事情中出现的问题也能给出很多不同角度的答案。而且能够做到比较好的换位思考,能够经常换位思考的人是很受欢迎的,人们也都爱和这样的人交流,这也说明了这样的人情商很高。而且思维不断的跳跃还能够创造出很多创意。

3,好奇心

牛人也都有这样的特质,就是对外界的事物都保持很高的好奇心,因为这些好奇心能够帮他们不断的发现,探索,学习到新知识,新技能。索尼创始人的口头禅就是“我绝对不能变成老人”,他从60岁开始学习网球,65岁开始学习滑雪,67岁开始学习潜水。

好奇心强大的人,会越来越觉得自己无知,因为他们知道未知的世界无穷无尽,这也是他们不断学习和前进的动力所在。从古至今,好奇心带来改变的故事数不胜数。牛顿对一个苹果产生好奇,于是发现了万有引力。瓦特对烧水壶上冒出的蒸汽十分好奇,最后改良了蒸汽机。伽利略也是看吊灯摇晃而好奇发现了单摆。中国的鲁班也是充满了好奇心。他从爬山时遇到小树叶割伤腿受到启发,发明了人们广泛使用的锯子。

4,简练表达能力

这个可以从两个方面来理解,一是不说废话,二是说对方听得懂的话。

无论我们现在上学还是工作,经常会有公开场合发言的机会,同样表达一个事情,有些人能够简练清晰的几句话就讲清楚,有些人则绕来绕去,半天也讲不清楚,听的人晕,可能也把自己绕晕了。简练表达背后的是对问题的分析,理解和总结能力。这就是牛人厉害的地方。

第二个就是面对不同水平的人,用什么方式来表达。记得曾经看过一个帖子《如何跟你家人讲清楚你的职业》。因为生活环境,年龄,学历很多因素造成,我们和生活在老家的家里人很难沟通,比如你是做互联网运营的,你回家如何跟你80岁的奶奶解释你的工作?比如你是做HTML5技术开发的,你如何跟在农村种地的大伯解释你的工作?所以,见什么人,说什么话是一种很厉害的能力。

5,对观点的态度

我见过一个人,在某个圈子里算是比较有名的。有一次几个人一起聊天,我们对于某一件事情产生了不同的观点,然后慢慢变成两队人的小型辩论了。但这个人并没有参与,他只是在旁边默默的看。当大家争执不下的时候,他才很谦虚的说,我想说说我的看法。先表明立场,说他支持哪个观点,然后又有理有据的讲了原因,但他并没有反对对方的观点,而是也给出了,他们有另外一个观点产生的原因。他的换位思考,和理性的分析,轻松化解了这场争论。

其实通过对观点的态度,就能判断出一个人是否具备独立思考的能力。我们经常看到微信里,会被各种没经过确认真伪的信息刷屏,比如前一阵的南海事件,北京暴雨,造谣可怕,更可怕的是无知的传谣。

6,对别人的态度

聪明人都是愿意和别人共赢的人,那些斤斤计较,私心很重的人是很难成为很成功的人的。很多人说牛人都是高高在上的,这个不假,他们通过培养,发展自己的某一项能力或强项,使自己能够成为某个领域的佼佼者,但是真正能够做大做强的人,都是谦虚的,他们不会势利眼,因为在他们眼里,共赢才是变得更加强大的基石,得人心者得天下。

网上看过一个段子“好的企业家需要:自黑,亲民,睡得少”。记得我大学刚毕业的时候,参加一个活动,嘉宾是李开复,袁岳,徐小平。当时第一次知道袁岳,后来网上查了他的个人信息,零点集团董事长,上海东方卫视《头脑风暴》主持人,出版著作40多部,各种tittle数不清,因为参加活动我拿了他的名片,有一次我特别想请教他一个问题,晚上10点多,就抱着试试看的态度发了一条很长的短信给他,但是半个小时之后,短信铃声响了,打开一看,正是他的回信,很认真的回答了我的问题,可以看出没有一点敷衍。当时我很震惊,这样的一个牛人,能给一个完全陌生的人回复短信。他的这种态度,让我敬佩至今。
可以给你身边的人脉做一个盘点,看看有没有这样的牛人,或者有潜力成为牛人的人。也可以看看自己,是否具备这几点。

测试Markdown

Emphasize emphasize
Strong Strong
A link.
Some text with a link and
another link.

code:

This is a
piece of code
in a block
This too

Header 1

Header 2

Header 3

Header 4

Header 5
Header 6

 

3. 高亮一段代码[^code]

@requires_authorization
class SomeClass:
pass

if __name__ == '__main__':
# A comment
print 'hello world'

4. 高效绘制 流程图

st=>start: Start
op=>operation: Your Operation
cond=>condition: Yes or No?
e=>end

st->op->cond
cond(yes)->e
cond(no)->op

5. 高效绘制 序列图

Alice->Bob: Hello Bob, how are you?
Note right of Bob: Bob thinks
Bob-->Alice: I am good thanks!

6. 绘制表格

项目 价格 数量
计算机 \$1600 5
手机 \$12 12
管线 \$1 234

替换 for in循环

由于每次迭代操作要搜索实例或原型的属性,for in循环每次迭代都要付出更多开销,因此它比其他类型循环执行速度慢一些。在同样的循环迭代操作中,其他类型循环执行速度比for in循环快7倍之多,因此推荐这样做:除非需要对数目不详的对象属性进行操作,否则避免使用for in循环。例如,迭代遍历一个有限的、已知的属性列表,使用其他循环类型更快,具体的使用模式如下:
var props = [“prop1”, “prop2”],
i = 0;
while (i < props.length){    process(object[props[i]]); } 此代码创建一个由成员和属性名构 成的队列。while循环用于遍历这几个属性并处理所对应的对象成员,而不是遍历对象的每个属性。此代码只关注感兴趣的属性,节约了循环时间。

解决问题的思路和设计代码的思路

解决问题的思路:
1.出现问题,除非是特别容易重现的,可以直接重现来解决,或者某个模块做过大的修改,之前的版本已经差别很大,有些问题不用再调查。否则每个能重现的问题都是巨大的福利,因为很多客户的问题都是没有重现环境的,所以要把握好能够重现的机会,不论多困难,找出背后的原因,而不是想着用新版本看能不能解决。因为这个问题在新的版本中可能被掩盖了,再找出这个问题就难了,就成了定时炸弹。你看,今天我们这个问题最后揪出多少严重问题,今天如果不在我的环境中重现,还不知道猴年马月能发现,那个时候花费的就不是一晚上。而且今天晚上发现了一连串的问题,这就是辛苦的收获。
2.而且发现一个线索必须要重视,比如onResize的问题,我说这个肯定是问题,贾贝说后面jschart会被覆盖,认为也许这个就不是错误,结果这个onResize中暴露了很多问题,尤其是删模型不删数据属性这种严重问题,所以千万不要放过一个线索。
3.还有就是用搜索代码的方法不能解决所有问题,比如今晚的,谁能想到是仪表盘上的别的模型的参数导致的问题,这样搜代码根本想不到这个问题。
4.你们没有做过支持真正产品的工程师,那时候就知道这些信息是多么宝贵,我现在后台的很多问题就是,有可能跑几个小时跑出一次错误,而且是内存错误,根本不知道怎么引起的,这种没有线索的问题排查起来就是殚精竭虑。
5.通过这种联合调试代码的方式配合,虽然花费了大量精力,异常辛苦,但是成果非常显著,这个即使我们坐在一个桌子旁边,也就是这个配合效率。所以希望形成一个解决问题的方法论,学到点思维方式,也是值得的。你会发现,正确的思维方式和解决问题的方式,是可以解决大部分问题,同样在设计新功能的时候一样可以用到。这就是珍贵的软能力。
6.今天用到的很多协调、配合方式、解决问题的方式(我对代码比较熟悉,董老师的环境中出现了bug, 我告诉他设置断点的位置,查看变量应该是什么值,断点场景中是什么值,以此来判断问题)也是在做项目管理中必备技能,否则很少几个人都协调不了,遇到问题也无法互相帮助,也无法统一代码质量和设计原则,更不要说几十个人,几百个人配合做一件事情了。

产品设计思路:
1.你要仔细思考我每次用的逻辑,第一如何保证行为是合理的,让使用者不会产生疑惑,不会被质疑的,同时还要在设计和实现上也是更容易的,更不需要增加各种不必要的分支的,更容易被抽象的
2.以后要有习惯把重要的数据结构通过注释的形式写在初始化函数或者对应的类前面。弱类型脚本语言最恐怖的就是数据结构的不稳定,查问题都不知道怎么查。
3.如果涉及到的点比较多.仔细思考想清楚,把每个点都记录到文档上,然后再把它们一点点放到一个设计的流程图里去,看这些点哪个被if覆盖,那个被elseif覆盖,哪个被else覆盖。用这样的方法,最后所有的需求都不会漏,同时设计还足够干净,不至于想到哪写到哪
记住,以后每次都得给我用这种设计方法:
1. 列出所有需要完成的行为;平时这些点一定不要漏,都是素材,一定记录下来,有可能现在没时间看。这些都是刚才第一步需要的素材。等到设计都做好了,它们都被考虑到了,它们就没用了。
2. 仔细思考有没有哪种行为没有被覆盖,保证需求足够完整。这是产品需求的穷举;
3. 仔细思考这些行为的分类,站在用户角度思考,是不是用户看到的类似的行为都得到同一类结果。这是产品需求的抽象总结;
4. 开始设计具体的实现逻辑,看上述的需求如果被设计全部覆盖,而且代码量最小,于是抽象的最好,封装的最好;
5.思考这个设计跟之前的哪个设计相关,是不是应该合并,还是扩展。
6. 思考这个设计本身有没有扩展性,会不会未来有新的变化可以轻松应对。

你把这个原则记到重要的地方,每次都这么去贯彻,再结合不停的模仿,设计能力和分析能力一定会提高,动手能力也一定能提高。

包括上次的两套模型参数的维护,使用,修改,合并也一样的设计思路。

不能每次都让我给掰开了揉碎了这么解释,会耽误我很大的精力,我的精力分散越多,这样项目的进度会受影响更大。当然,这个也不是一次两次就能完全融会贯通,只要有这个理念和意识,然后一点点强化,总能解决。

然后就是平时这些点一定不要漏,都是素材,一定记录下来,有可能现在没时间看。这些都是刚才第一步需要的素材。等到设计都做好了,它们都被考虑到了,它们就没用了。

这就是书越读越厚的过程,后面几步就是书越读越薄的过程。

关键是需求怎么来的
我们在考虑的时候,就是需求不全,考虑容易出现偏差
这个其实是需求的取舍问题
大产品经理->产品经理->研发人员的推演和延伸、扩展,现在我就是大产品经理和产品经理,你们在做的过程中也反向向产品经理的角色渗透一部分,小公司都不会分的那么清晰。所以多思考,多沟通。拿不定主意,不知道把控风险的,我会把控,因为我要让产品适应市场,让产品生存,让产品盈利。
平时大家可以多关注别的产品,多关注别的产品的功能逻辑,以及一些优秀的产品经理的思考问题的方式,以及优秀的产品的设计。但是,我更建议大家多关注一些具体的技术实现,它跟产品管理完全不是一套路,也不是一个方向。当然,落地最重要,具体的经验最重要,空有理论是最没有价值的。从实践中总结出自己的经验,再去看优秀的产品和技术经验,再去碰撞是最有效的路。否则容易要么闭门造车,要么空中楼阁。