现在的 IM 在设计上是基于会话的，多个人可以组成一个会话，相当于一个聊天室，当一个人加入到一个会话后，就可以看到从加入开始之后这个聊天室里所有参与人的发言。有的 IM 会把两人对话也抽象成同一个东西，也可能出于优化的考虑把双人对话特殊处理。

所以，这些 IM 在操作界面上会有一个会话列表：表现出来会是联系人名单、聊天群列表等等。选中会话列表中的项目，进入会话查看聊天记录、发言，就是这类 IM 的使用逻辑。

我认为，这种对即时通讯的抽象方式，其实是不适合办公环境的。和日常个人社交环境不同，办公群体其实是一个相对关系密切的团体，我们通常不会拉黑一个同事不让他给你发消息，也不会拒收公司发的通告，也不会因为一个同事平常不和你打交道就拒绝建立联系。项目组里的讨论，也未见得是多么保密的事情，需要防止隔壁组的同事旁听。你也很少会在办公 IM 上和妹子私聊谈人生理想。

我们这几年使用腾讯的 RTX 作为公司办公使用，我就感受到了太多这类设计缺陷。比如，有同事找我有事，我忽略了他的私聊信息；找人一般在对方活跃的项目群组里吼；程序群沦为了日常扯淡的位置，常常同时讨论着不同的问题，线索及其混乱。“群”这个设计，我在很多年前就思考过 ，我一直觉得需要在根本上换个角度看待社交聊天的需求。

我现在的想法是这样的：

作为办公 IM ，我们不应该基于固定会话（群）来设计，而应该是“通知”和“话题”。

所谓通知，就是有人发起了一条消息，他需要把这条消息传达给某些对象，对象可以是人，也可以是某个组织：比如程序、游戏项目组、等等。

组织并非是群那样的聊天室，而仅仅是一个标签，由人来关注标签，而不是去组织这个聊天室里有多少听众。

而话题，则是由消息或旧话题衍生而来。任何通知消息、话题内部消息，都可以变成一个新话题。话题也可以包含在一则消息里转发给某个对象。

用户的客户端应该把所有的通知按时间线排列在一起，呈现在同一个地方。也就是说，无论是谁给我发消息（默认就是通知）都应该投递在一起，而不是像现在 RTX 那样只是在系统托盘里闪烁提醒、也不是微信 qq 那样，联系人名单上多出一个小红点。

而一旦我回复一个通知消息，其实就把这则通知转化成了一个话题，在时间线上，话题内的消息是归属在一起的。同一时刻，无论你的思维切换多么快，其实在短时间内你只能聚焦在一个话题上，所以客户端界面是很容易表达的，把当前话题展开在主界面（通知的时间线）即可，切换话题后自然可以折叠起来。

话题并不是聊天室、它更像是论坛的帖子。一个话题可以有很多人参与（至少发言一次），更应该支持更多的人浏览。我们不应该按聊天室的思路：用户只有在加入聊天室的那一刻开始，才能收到后续的消息，而应该像论坛那样，他只是打开了这个话题帖，可以随时聊天过去到现在发生的事情。话题内的任何一个消息，都可以由用户展开为新话题，老话题对新话题只是一个引用链接而已，并不需要有层级关系，我们也可以把任意一个话题或尚未转化为话题的消息转发出去，如果有人对他评论，就生成了新话题。

话题是一个有时效性的东西，对于办公来说，如果一个话题超过 8 小时没有新的消息，就可以认为这个话题已经结束了。但是事后我们依然可以对老话题浏览，或是继续讨论，而继续讨论就是生成的一个新话题了。

只要生成话题足够方便，每个用户的主时间线上就只会有不多的通知消息，信息传达更为有效。而管理每天的消息、检索旧消息也有很强的时间线。不像现有的 IM 群聊天，每天的聊天内容会被自然的组织成话题，这些话题上标识了参与人数、归属的组织的 tag 、继承于哪个父话题或通知、经历的时间段、衍生出哪些后续话题，等等。

即使是两个人之间的对话，也同样应该是话题的形式，而不应该把消息直接组织成一长串的聊天历史。话题未必有明确的主题，只是一种更自然的信息聚合形式而已。

对于办公场合来说，有意个最重要的优势：用户群有足够的自律。基于这种自律，我认为上面的思路若实现出来很容易推广使用。

在自律之外，或许还需要一些权限管理。这些权限管理应该是相对松散简单的，主要是限制用户订阅特定组织的 tag （比如一般员工不能订阅管理层的 tag ），限制围观特定话题（比如两人之间的私聊话题默认就是不对第三人开放权限的），话题可以锁定不准转发。权限设置的细节还需要进一步推敲。
 
本文转自云风的BLOG，原文地址http://blog.codingnow.com/ 查看全部

   据GSMA预期，到2020年，全球互联设备将突破270亿，移动互联设备有望达到105亿，新的市场机遇将进一步增多。自动上报家中燃气数据、远程开关气阀、精准透明计费、自动调节远程定时控制路灯等，基于新一代物联网的新型智慧产品正在走入我们的生产生活。

   开发一款智能硬件产品涉及的环节很多。本次活动，APICloud联合华强聚丰和智石科技，从样品生产、App开发和近场通讯技术在智能硬件中的应用跟大家分享智能硬件产品如何快速从0到1！
 
活动概况
【活动时间】2017年8月19日（周六），13:30-16:30
【面向人群】制造业企业、智能硬件管理层、产品负责人、技术负责人，其他相关从业者
【活动咨询/合作】请加微信：appdev1，备注819活动议程
【13:30-14:00】签到
【14:00-14:40】如何快速完成样品生产
内容概要：产品硬件开发者希望快速拿到样品，进行方案验证和调试，发现设计问题，快速进行方案修正，以便进入下一开发环节，完成开发工作。怎样解决这些困难？怎样才能让生产环节快速顺利完成样品生产？
【14:40-15:20】自主研发or外包？智能硬件App开发指南
内容概要：现在市场上智能硬件往往需要一款App配合，无论是控制设备还是查看数据。企业不但需要考虑成本，还要兼顾产品体验。本环节APICloud将会为大家介绍App开发技术如何选型；自己招团队与找外包的对比；以及项目准备、开发、测试、上线各个阶段可能遇到的问题和注意事项。
【15:20-16:00】室内精准位置物联网络搭建
【16:00-】幸运抽奖&自由交流分享嘉宾
















报名地址活动报名 查看全部

【活动时间】2017年8月19日（周六），13:30-16:30

【面向人群】制造业企业、智能硬件管理层、产品负责人、技术负责人，其他相关从业者

【活动咨询/合作】请加微信：appdev1，备注819

【13:30-14:00】签到

【14:00-14:40】如何快速完成样品生产

内容概要：产品硬件开发者希望快速拿到样品，进行方案验证和调试，发现设计问题，快速进行方案修正，以便进入下一开发环节，完成开发工作。怎样解决这些困难？怎样才能让生产环节快速顺利完成样品生产？

【14:40-15:20】自主研发or外包？智能硬件App开发指南

内容概要：现在市场上智能硬件往往需要一款App配合，无论是控制设备还是查看数据。企业不但需要考虑成本，还要兼顾产品体验。本环节APICloud将会为大家介绍App开发技术如何选型；自己招团队与找外包的对比；以及项目准备、开发、测试、上线各个阶段可能遇到的问题和注意事项。

【15:20-16:00】室内精准位置物联网络搭建

【16:00-】幸运抽奖&自由交流

8月8日21时19分在四川阿坝九寨沟县发生7.0级地震，地震发生后社会各界纷纷为灾区祈福。使用各种语言的程序员也不甘示弱吗，争先恐后地用自己的语言为灾区祈福。我听说过的语言差不多都有了。

~trace("ActionScript程序员为灾区祈福！");
~TEXT_IO.PUT_LINE ("Ada程序员为灾区祈福！");
~<% Response.Write("ASP程序员为灾区祈福！") %>
~MsgBox(1,'','AutoIt程序员为灾区祈福！')
~BEGIN { print "AWK程序员为灾区祈福！" }
~echo 'Bash程序员为灾区祈福！'
~? "BASIC程序员为灾区祈福！"
~WRITES ("BCPL程序员为灾区祈福")
~Print "BlitzBasic程序员为灾区祈福！"
~print "BOO程序员为灾区祈福！"
~printf("C程序员为灾区祈福！");
~cout << "C++程序员为灾区祈福！"<<endl;
~System.Console.WriteLine("C#程序员为灾区祈福");
~PROCEDURE DIVISION.DISPLAY "COBOL程序员为灾区祈福！".STOP RUN.
~echo Linux Shell程序员为灾区祈福！
~io.put_string("Eiffel程序员为灾区祈福！")
~hello_world() -> io:fwrite("Erlang程序员为灾区祈福！").
~." Forth程序员为灾区祈福！" CR
~WRITE(*,*) 'Fortran程序员为灾区祈福！'
~HTML程序员为灾区祈福！
~System.out.println("Java程序员为灾区祈福！");
~<%=("JSP程序员为灾区祈福！")%>
~(format t "Lisp程序员为灾区祈福！")
~print "Lua程序员为灾区祈福！"
~Print["Mathematica程序员为灾区祈福！"]
~Nuva程序员为灾区祈福！
~NSLog(@"Objective-C程序员为灾区祈福！");
~print_endline "OCaml程序员为灾区祈福！";
~writeln('Pascal程序员为灾区祈福！');
~say "Perl程序员为灾区祈福！";
~<?= "PHP程序员为灾区祈福！"?>~
~write("Pike程序员为灾区祈福！");
~write("Prolog程序员为灾区祈福！").
~#!/usr/bin/env pythonprint("Python程序员为灾区祈福！")
~say "REXX程序员为灾区祈福！"
~#!/usr/bin/rubyputs "Ruby程序员为灾区祈福！"
~Om:"Sbyke Laborana程序员为灾区祈福！"
~(display "Scheme程序员为灾区祈福！")
~sed -ne '1s/.*/sed程序员为灾区祈福/p'
~writeln("Seed7程序员为灾区祈福！");
~Transcript show: 'Smalltalk程序员为灾区祈福！'
~TextWindow.WriteLine("Small Basic程序员为灾区祈福！")
~OUTPUT = "SNOBOL程序员为灾区祈福！"
~print 'SQL程序员为灾区祈福！'
~println("Swift程序员为灾区祈福！")
~#!/usr/local/bin/tclputs "Tcl程序员为灾区祈福！"
~? "TScript程序员为灾区祈福！"
~put "Turing程序员为灾区祈福！"
~<includeonly>UNIX-style shell程序员为灾区祈福！</includeonly>
~ShowMessage('Delphi程序员为灾区祈福！');
~Print "Visual Basic程序员为灾区祈福！"
~? "Visual FoxPro程序员为灾区祈福！"
~QLabel label("X11程序员为灾区祈福！");
~alert("JavaScript程序员为灾区祈福！");
~(PostScript程序员为灾区祈福！) show
~println("Scala程序员为灾区祈福！")
~println("Kotlin程序员为灾区祈福！");
~调试输出(“易语言程序员为灾区祈福！”） 查看全部

经常在网上看到各种标题为“Android程序员”、“Java程序员”、“PHP程序员”、“C/C++程序员”的招聘帖子，但这种招聘方式，很难找到好的人才。语言只是一种工具，对一个聪明的程序员来说，用没用过什么工具主要是由他原来的工作需要决定，并不能代表他全部的技能。

软件行业是一个非常强调人的价值的行业，价值就体现在有效的推动产品前进，而语言只是实现这个价值的工具。





一个软件产品往往涉及很多方面的知识，比如网络、数据库、Cache、编译环境工具等。如果这些必要基础知识不足，很难很好的独立完成一个产品的某个部分。

另一方面，一个人的聪明程度、对新知识的好奇心、自我驱动意识、为问题找到最佳解决方案的决心，才是他能不能成为一个好程序员的关键。举个例子，我的一位在某米当cto学长的告诉我，有位同事本来是服务器端以C#语言为主做开发的，完全没有过android开发经验，但他表现出对移动开发很有兴趣，并且在做服务器端开发时，表现出良好的学习能力，后来我把他调到Android组，负责android SDK和APNs相关的工作，结果只花了几个星期，Android SDK的稳定性大幅提升，解决了多个致命问题。

不要仅仅把自己定位为某种语言的程序员，说自己是Java程序员，C#程序员，Python程序员等等。一方面会限制自己的发展，一方面对团队整体的能力提升也不利。几乎所有的语言都有它自己的适用场景，在合适的地方用合适的语言，才能极大的提升生产效率。
正确的做法是，首先要有良好的基础知识，深刻的掌握2～3门语言，然后适用于不同场景的语言要了解概念。基础知识包括各种计算机原理、数据方面的知识，在学校没认真学的，现在有时间也要补充。语言方面比如掌握了C/Java，那C++/Python/Bash/Javascript/CSS等都可以了解下概念，至少要理解在一个完整的产品链里，它们分别适用于哪个环节。

标题用“请不要说自己是Android程序员”没有贬低Android程序员的意思，Java是目前被采用得最多的语言，主要用Java的程序员里，也是有大量牛人。另外，同样的，也不要说自己是C程序员、Python程序员。

 古语说的好，“书中自有黄金屋”。这句话告诉我们书籍是学习知识的第一大根本方向。在与Java相关的专业书籍中，相继记述着关于这门课程的基础知识及进阶内容，先易后难、步步深入，非常适合初学者去学习。
  虚心求教不可少。
往往很多高深莫测，经验丰富，功力深厚的人都埋藏在自己的身边，不容自己去察觉。所以如果大家想要从事Java行业，不妨请假身边从事过该行业的朋友，求学不在高低贵贱之分，只要碰到不懂的地方，就去虚心求教，世界这么大，而且这门知识又是如此让人追捧，比自己懂的人岂止千百?从这些人身上自己一定能够受益匪浅。

现在以Java语言为主的工作非常之多，另外在学校里就以学习Java为主的人也越来越多。但是，从学校就以学习Java这种高级语言为主的人，很多基础知识比较薄弱。高级语言掩盖了太多细节，提高了生产力，但在学习阶段，却不利于基础知识累积。




“Nicholas C. Zakas是全世界最著名的JavaScript程序员之一，之前是在雅虎将近工作5年。三年前，他写了一篇长文，回顾自己的职业生涯，提到七个对他来说最重要的建议，希望对大家的职业生涯有帮助：

1、 不要别人点什么，就做什么

我的第一份工作，只干了8个月，那家公司就倒闭了。我问经理，接下来我该怎么办，他说："小伙子，千万不要当一个被人点菜的厨师，别人点什么，你就烧什么。不要接受那样一份工作，别人下命令你该干什么，以及怎么干。你要去一个地方，那里的人肯定你对产品的想法，相信你的能力，放手让你去做。"

我从此明白，单单实现一个产品是不够的，你还必须参与决定怎么实现。好的工程师并不仅仅服从命令，而且还给出反馈，帮助产品的拥有者改进它。

2、 推销自己




我进入雅虎公司以后，经理有一天跟我谈话，他觉得我还做得不够。

"你工作得很好，代码看上去不错，很少出Bug。但是，问题是别人都没看到这一点。为了让其他人相信你，你必须首先让别人知道你做了什么。你需要推销自己，引起别人的注意。"

我这才意识到，即使做出了很好的工作，别人都不知道，也没用。做一个角落里静静编码的工程师，并不可取。你的主管会支持你，但是他没法替你宣传。公司的其他人需要明白你的价值，最好的办法就是告诉别人你做了什么。一封简单的Email："嗨，我完成了XXX，欢迎将你的想法告诉我"，就很管用。

3、 学会带领团队
工作几年后，已经没人怀疑我的技术能力了，大家知道我能写出高质量的可靠代码。有一次，我问主管，怎么才能得到提升，他说："当你的技术能力过关以后，就要考验你与他人相处的能力了。"
于是，我看到了，自己缺乏的是领导能力，如何带领一个团队，有效地与其他人协同工作，取到更大的成果。

4、 生活才是最重要的
有一段时间，我在雅虎公司很有挫折感，对公司的一些做法不认同，经常会对别人发火。我问一个同事，他怎么能对这种事情保持平静，他回答："你要想通，这一切并不重要。有人提交了烂代码，网站下线了，又怎么样？工作并不是你的整个生活。它们不是真正的问题，只是工作上的问题。真正重要的事情都发生在工作以外。我回到家，家里人正在等我，这才重要啊。"
从此，我就把工作和生活分开了，只把它当作"工作问题"看待。这样一来，我对工作就总能心平气和，与人交流也更顺利了。
5、 自己找到道路
我被提升为主管以后，不知道该怎么做。我请教了上级，他回答："以前都是我们告诉你做什么，从现在开始，你必须自己回答这个问题了，我期待你来告诉我，什么事情需要做。"
很多工程师都没有完成这个转变，如果能够做到，可能就说明你成熟了，学会了取舍。你不可能把时间花在所有事情上面，必须找到一个重点。
6、 把自己当成主人

我每天要开很多会，有些会议我根本无话可说。我对一个朋友说，我不知道自己为什么要参加这个会，也没有什么可以贡献，他说："不要再去开这样的会了。你参加一个会，那是因为你参与了某件事。如果不确定自己为什么要在场，就停下来问。如果这件事不需要你，就离开。不要从头到尾都静静地参加一个会，要把自己当成负责人，大家会相信你的。"
从那时起，我从没有一声不发地参加会议。我确保只参加那些需要我参加的会议。
7、 找到水平更高的人
最后，让我从自己的经历出发，给我的学员一个建议。
"找到那些比你水平更高、更聪明的人，尽量和他们在一起，吃饭或者喝咖啡，向他们讨教，了解他们拥有的知识。你的职业，甚至你的生活，都会因此变得更好。"
 我的感受是IT行业是当今社会的热门行业，说它热门是因为它的发展潜力是无穷的，所以我们能进入到这个行业是一种幸运。在此，我特别感谢上家公司带我教我前辈们和师傅，在学习期间给了我莫大的帮助，在我遇到困难时，给我很大的鼓励和帮助，让我更加有信心坚持下来，找到工作。最后送大家一句话：相信自己没有选错行业，相信自己有立足的能力，为自己制定明确的目标，然后努力地去学习、体会、感悟、进步！
  查看全部