Hello world!
Welcome to WordPress. This is your first post. Edit or delete it, then start writing!
和程序员男朋友过情人节都是这样的
◆ 01 我一直期望着跨年的时候，我们能有机会一起看着烟火倒计时，然后在跨年钟声响起的那一瞬间，拥个抱接个吻什么的。 2013年跨年。舍友们出去开了个房间，看跨年晚会，唱歌，等等。我对某人说，我们也一起跨年吧。 他说，好啊。 然后抱上了电脑，把我带到了实验室。 “你挑个电影，我们一起看好了。” 我在心里叹了口气，挑了个《爱在黎明破晓时》系列。 看了一会儿之后，发现他心不在焉。 “怎么了？” “电影太无聊了。” 我的兴致也不是很大，便说，你看你自己喜欢的吧，我看这个。 他就开心地去看不知道什么科幻片去了。 看完电影之后，他说，不早了，回寝室吧。 我说，这就回啊。 他不解，不回待会宿舍关门了啊。 我默默把看零点的烟火熄灭在心底。 第二天看到他写了篇博客，其中有一句：“从13到14，这大概是我们一生一世的一个开始。” 好吧，我承认我又没用的感动了。 ◆ 02 2013年1月4日是我们在一起的第一个重大的日子，所谓千年或百年（或其他不知道多少年）难得一遇的“爱你一生一世”。 我像每一个恋爱中的小女生一样对这个浪漫的日子充满了期待与憧憬，早早在他耳边嘟囔。相信每一个初谈恋爱的小女生，总是希望把青春偶像剧里上演的风花雪月浪漫剧情，通通演绎一遍。 然而整个上午，他都窝在实验室里，不知折腾些什么。 被冷落的我自觉无趣，窝在寝室里看电影，大概是《失恋三十三天》一类。 下午三点左右，收到了某人的短信：“要不要出去逛逛啊？” 我没好气地回复：“逛什么？” “今天是201314啊，这么好的日子，不过岂不是浪费了么？” “原来你还知道啊……所以要去哪里？” “你看呗。” 已经是半下午，只能在学校附近活动了。我看了一圈地图，选择了学校附近的一个不知道是寺庙还是塔的遗址的公园——西安有很多这种免费的遗址公园。所谓遗址公园，其实就是一个据说那里曾树立着拥有怎样怎样价值的建筑发生过怎样怎样宏大的历史事件而如今什么也看不到了只剩下刚栽的树木和不副实的名字的公园。 步行过去，大约二十分钟。公园里什么都没有，也不对，有在冬日里只剩下枝丫了的树，和一汪已经结成冰了的…冰。 也不是下雪天，没法儿不撑伞走着走着就到白头。 唯一的娱乐活动是我在冰上面蹦跶了一下，因为我想知道北方的冰有多厚。不过我也只敢在岸边试了一试。 嗯，还有什么呢，某人突然抱住了我… [...]
1秒50万字的关键词匹配（js实现）
在论坛和聊天室这样的场景里，为了保证用户体验，我们经常需要屏蔽很多不良词语。对于单个关键词查找，自然是indexOf、正则那样的方式效率比较高。但对于关键词较多的情况下，多次重复调用indexOf、正则的话去匹配全文的话，性能消耗非常大。由于目标字符串通常来说体积都比较大，所以必须要保证一次遍历就得到结果。根据这样的需求，很容易就想到对全文每个字符依次匹配的方式。比如对于这段文字：“Mike Jordan had said "Just do IT", so Mark has been a coder.”，假如我们的关键词是“Mike”“Mark”，那么可以遍历整句话，当找到“M”就接着看能不能匹配到“i”或者“a”，能一直匹配到最后则成功找到一个关键词，否则继续遍历。那么关键词的结构就应该是这样的： 1 var keywords = { 2 M: { 3 i: { 4 k: { 5 e: {end: true} 6 } 7 }, [...]
传统的程序员真的将会被淘汰么？
要成为当今软件开发中受人尊敬的专业人士，你需要掌握各种技能，而且达到高水平的专业级别。最起码，你需要能够把你的英语解决方案翻译成软件实现。 不仅技术上要正确，在业务上也得可行。因此，对业务有一个深刻的理解总是没有坏处的。这使得你可以有效地收集和谈判客户的需求，并确保软件能够经过时间的 考验。企业希望软件是一个长期的投资，能够在几年甚至几十年之后依然物尽其用。很少有希望软件只存活几个星期的。如果真的有，那可真是一个糟糕的投资。 遗传编程 你可能会觉得自动化的软件开发是一个奇思妙想，甚至觉得这是不可能的。但是遗传编程告诉我们nothing is impossible。软件会产生变异，改变它们的指令，努力顺利发展以变得更适合。在每个突变后，它们将自行评估它们是否正趋向于期望的输出。这里对于 合适的评估是由测试提供的。而且是大量的测试。这些测试都封装了经过时间、空间和功能性制约的业务逻辑。突变越合适，通过的测试越多。这是值得重申的是， 我们不应该关心生成实现的细节。事实上，生成多个符合要求的解决方案是完全合理的。要减少解决方案只需要增加更多限制问题就可以了。 软件开发人员的传统角色将会被淘汰。他们很快会被重新定位到设计、开发和维护测试。即，计算机的程序设计将变得不必要，因为它们自己就能编程。这种 范式将对软件行业产生翻天覆地的影响。改变业务需求，直接改变测试，而这会触发软件自动化的进化。修改现有代码，以满足新兴需求的压力将一去不复返。计算 机会做好这件事：因为它不会有重新开始的顾虑。它也不关心可维护性，并且最后一定更兼容不断变化的业务需求。 说了这么多，我决定把将来的重心放到测试上，以应对将来软件行业的变化。那么，你呢？ 对软件开发的熟练要求放宽了 在美国，对软件开发人员的需求一直在增长，但对技能熟练程度的要求却在降低。计算机编程退步到了寻找正确的软件库然后将它们串接起来得程度。那么你 如何解释软件或平台作为服务的迅速崛起？是的，有时你是需要弄清楚哪些组件装配在一起才最适合你的特定问题，而且，当找不到这样的组件时，你必须自己动手 创建。但是，现在的问题是，很多时候，该软件已经存在。在这种情况下，你的工作就是无聊重复的顺序：选择库，联合库，按照需求测试。 但是先等等！你可能会认为，编程还囊括了很多合同规定的内容。当然，我们可以构建一个已经构建过的结构，但它们还需要个性化，才能适应特定的业务需 求。这无疑需要一定程度技术和智慧的，对吧？而对于这种说法，我承认。是的，业务需求常常是非常多样和特殊的，然而现在却在开始渐渐地变得大同小异。 因此，选择组件来满足业务需求成为了自动化的主要目标。既然有这么多潜在的组合，那么那些永远不需要睡觉、吃饭和休息的员工才是最完美的员工。人工辅助软件开发的时代正在到来。也就是说，计算机将执行大部分的开发步骤，而人类只需要协助它们即可。 在这个新的时代，人工智能研究人员和测试人员将占据统治地位。人工智能研究人员负责想出大致的思路。他们将确定需要解决哪些问题，即通过给定的输入 描述期望的输出。然后，测试人员编写断言这个问题确实被解决的测试。也就是说，验证正确的输出是由给定的输入确定的。此时的计算机负责将给定的输入转换为 所需的输出。 相关链接 > 产品 [...]
程序员，你能从bug中学习什么？
益处 Nassim Nicholas Taleb 在《Antifragile》中写到：“错误包含丰富的信息”。我完全同意这个观点。Bug 帮助我们更好地理解系统，告诉我们怎样提高编码、测试和调试技巧。所以我认为尽可能从 bug 中学习经验，是再正常不过的事了。 我发现为每个有趣的bug记录下来，让我轻易学习到很多。在记录的行为中我会对发生的事情思考得更深刻。同样，一旦记录下来，我可以在之后检查发生的事情。偶尔，我也会浏览文件，只阅读教训部分，对我认为是从 bug 中学到的最有价值的经验加强记忆。 我记录 bug 文件至今已经有 13 年了。这是一段漫长的时间，但是我坚持下来了，因为作为一名程序员，它帮助我进步。尝试一下吧，看看它是否也对你有益！ 我有一个命名为 bugs.txt 的纯文本文件。在文件的顶部是一个具备所有标题的模板，但是没有包含信息。当我添加一个新的记录，我复制模板部分，粘贴在模板下面。然后完成记录并且填满信息。大多数展示在上面例子中的 fields 应该是不需要声明的。 有必要指出这并不是 bug 追踪器。我并没有添加所有我修复的 bug 。例如，如果我只是忘记在代码中添加声明，一旦发生这种情况，我就意识到问题出在哪里了，我并不会添加这条记录。仅仅当 bug 本身，或是修复，或是调试过程特别有趣，我才会添加一条新的记录。通常，是我导致了这个 bug。但是偶尔，特别是花几天时间才追踪到的困难 bug,尽管不是我造成的我也会添加一条记录。 一旦修复了一个 bug，我的第一反应是松了口气然后继续前进。我试着一更正后就写下这个记录。这时我的脑海中依然清晰保留所有的细节。拖延会让精确回忆发生的事情变得很困难（或者我压根忘记写下这条记录）。 至今，我已经有 194 条记录，平均每个月有一条新的记录。最重要的是教训部分。这里需要自我反省。是什么导致这个 [...]
来，做一个问卷调查（有抽奖！）
前言 “小王，明天公司在***举办一个xxx产品发布会，你今天准备2000份问卷调查。还有，我们这次还做一个抽奖活动，也记得弄一个抽奖箱和一些抽奖球哦。” …… 活动结束了，小王想起早上捧着这2000张问卷和抽奖箱的情景，生平第一次对弘二头肌起了念想。回过神来看着桌子上回收回来的问卷，整整齐齐的像座小山一样好看，但领导依然不太满意，因为只回收了1000来张。可是1000多张的样本已经足够了呀，统计也很花时间的呀。小王本想反驳，但他什么也没说，只是下意识地摸了摸自己的背包，包里装着那丢失的900多张问卷。 以上剧情根据真实故事改编，如有雷同，算你倒霉。 数字化大背景 现在还有不少活动是用纸质问卷来做调查的，几千张纸是小钱，但后期统计这一堆数据可是费神费力的苦力活。以前设备落后，手机上做问卷体验太差。但现在是80岁大爷都会玩智能手机的年代，一个二维码也解决了入口问题，在线调查问卷的体验也就上来了。再加上现在办个活动什么的都是用微信宣传微信组织，配合一点抽奖活动，观众们还是愿意去回答的。既然已经具备了在线问卷的大环境，下面就让小茄带大家来做一个在线问卷调查吧。 需求 先来分析一下需求。 1、在线问卷调查的使用者都是市场运营的工作人员，他们对编程的了解很少，所以后台操作必须简单明了。 2、输入为问题信息，输出为回答统计信息，输出需要使用可视化图表呈现，必要时也提供元数据。 3、最好能带一点圈粉属性，扫一扫关注公众号然后才开始答题。硬生生让人关注公众号，许多人可能无动于衷，但增加了一个问卷和抽奖的梗，关注公众号就显得非常合理自然。 4、最好能带一点统计功能，统计一下到底多少人打开了页面，从而为后续改进提供数据分析支撑。 其中1、2是刚需，3、4是软需。 后端 简单分析可以发现，开发这个小应用最主要的工作是在后端开发部分，而且这个主要是以数据处理为主，显然采用面向数据库编程的方式来开发更为合适。 面向数据库开发第一步，先来定义数据库吧。先使用excel做出相应的表格，大概是这样的： 然后就是分表写数据库，将question、options、answer分成3个表，以questionID做索引关联3个表，另外用户信息和奖品信息也要用一个数据表来保存。本来这里想用MySQL for Excel来实现，这样市场的妹子们也能简单上手。不过想想还是导出一个sql脚本更好，毕竟这样就可以手把手教妹子怎么把问卷数据写到sql文件里面了。(/▽╲) 问卷数据的读写都可以用WeX5通用的查询接口来实现数据的读写，这里不再赘述。 这里要自己写的是抽奖算法的实现，要点是保证中奖几率的均一性。但是，算法也不能太死板，主要看脸，哦不，主要看奖品大小。 如果有大奖，那么大奖单独出来所有人抽一次会比较好，这样能有效活跃起现场气氛。这种情况下可以设置一个抽奖期间，后台统计这个期间内的人数，然后在这个人数里面随机选中一个即可。如果都是些小奖品，那么肯定就是先答题后抽奖，抽奖结果要马上呈现。也就是每个观众抽奖的时刻是不同的，而且抽奖的人数也是未知的，这种情况下要保证前后抽奖的人都有相同的中奖几率，而且要把奖品发完的话，好像很难的样子。但是，既然是小奖品，按照先来先得发不完也没事的原则，每次都查询当前奖品池的奖品，如果还有奖品则用随机数判断是否中奖，否则就不中奖就完事了，简单粗暴。 所以说，一切以实际出发，把重心放到重要的事上，把吃奶的力用到吃奶上，才是王道。 贴个抽奖算法的简单实现： 1 public static JSONObject drawPrize(JSONObject params, ActionContext context) throws SQLException, [...]