Mobabel Blog

0

[转]时间复杂度、空间复杂度,如何”不复杂“地学?

1. 写在之前 我们都知道,对于同一个问题来说,可以有多种解决问题的算法。尽管算法不是唯一的,但是对于问题本身来说相对好的算法还是存在的,这里可能有人会问区分好坏的标准是什么?这个要从「时效」和「存储」两方面来看。 人总是贪婪的,在做一件事的时候,我们总是期望着可以付出最少的时间、精力或者金钱来获得最大的回报,这个类比到算法上也同样适用,那就是花最少的时间和最少的存储做成最棒的解决办法,所以好的算法应该具备时效高和存储低的特点。 这里的「时效」是指时间效率,也就是算法的执行时间,对于同一个问题的多种不同解决算法,执行时间越短的算法效率越高,越长的效率越低;「存储」是指算法在执行的时候需要的存储空间,主要是指算法程序运行的时候所占用的内存空间。

0

我们正变成当初我们讨厌的那类人

一个朋友说他把他朋友圈里分享抖音的人全拉黑了,我没说啥,因为我自己闲时偶尔也刷刷抖音,虽不到在朋友圈分享的狂热度,但至少在刷到有意思的视频时我是有分享的意愿的。况且很多抖音网红歌真的蛮好听的,旋律轻快,歌词直白,听时脑海里会浮现蓝天白云和清空万里。生活和工作中已经有那么多烦心的事,看看网红的微笑,听听朗朗上口的歌,就那么短短几分钟做做鸵鸟其实也是另一种身心放松。至于歌词没有内涵,我想,在我们二十岁左右的时候,对生活对爱情的理解,也不一定有现在的年轻人那么深刻吧。

0

[转]成为DevOps/SRE工程师有多难?看看这份必备技能清单

这个列表并非详尽无遗,只是列举了技术基础、必须知道的技能和一些随机的想法。可以用它们作为一个清单来评估你自己或其他人,或者为下一次面试 DevOps/SRE(Site Reliability Engineers,网站可靠性工程师)工作做准备。补充下,这个清单是比较个人的想法。 准备好看这一份清单了吗?

0

[转]小型系统如何“微服务”开发

提到“微服务”,我相信网上各种“微服务”的演变案例都会给人一种“因大而分”的前提错觉,这可能会导致许多的“小白”产生没有机会接触“大项目”而对“微服务”可望而不可及也。当然,这种错觉的产生可能更多来源自于各种“微技术”的“层出不穷”所以“眼花缭乱”,例如Spring Cloud。虽然“大项目”机会不多,但也阻止不了“钉子们”通过教程把微技术跑一遍来装饰自己可以“微”起来的自信。

0

[转]程序员吃的是青春饭?本质上取决于……

导读:你是否曾经认真思考过——毕业3-5年、10年,乃至更久后,我们希望成为什么样的人?作为一名技术人,我们要如何规划自己的职业发展生涯?网上热议的“35岁中年危机”,本质上又因什么而焦虑?今天,阿里资深技术专家毗卢,将带来自己的思考与理解,希望对大家有所启发。

[转]软件项目中,需求怎么做? 0

[转]软件项目中,需求怎么做?

对于软件开发团队而言,软件开发的全过程是:做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署;其中,“做什么”对应的是需求分析过程,“怎么做”对应于软件架构设计过程,“做”对应于开发过程,“成果检验”对应于测试,部署由运维团队执行后,如果达到用户的要求,则软件上线后进入软件的运行生命周期。

0

[转]没有功能需求设计文档?对不起,拒绝开发!

1. 0 题记 在很多软件公司,特别是一些创业型的团队中,对于这样的情景可能大家都很熟悉:项目经理或者产品经理(产品狗)口头或者简单记录一下软件产品的大致要做的功能,直接就让研发团队的兄弟(程序猿)去狂撸代码。然后他就去喝茶撩妹或者回家陪老婆了… 这种撸起袖子就开干的方式,看似简单高效,便于直接沟通,能够快速迭代。却不知,发现没有一份正规且实时更新的功能需求设计文档,会付出三四倍的代价来弥补。 最终会引发一场产品狗和程序猿之间的“猿狗大战”…

[转]大规模数据处理的演化 0

[转]大规模数据处理的演化

本文重点讨论了大数据系统发展的历史轨迹,行文轻松活泼,内容通俗易懂,是一篇茶余饭后用来作为大数据谈资的不严肃说明文。本文翻译自《Streaming System》最后一章《The Evolution of Large-Scale Data Processing》,在探讨流式系统方面本书是市面上难得一见的深度书籍,非常值得学习。

[转]千万小时机器学习训练后,我从趟过的坑中学习到的 16 个技巧 0

[转]千万小时机器学习训练后,我从趟过的坑中学习到的 16 个技巧

在经历成千上万个小时机器学习训练时间后,计算机并不是唯一学到很多东西的角色,作为开发者和训练者的我们也犯了很多错误,修复了许多错误,从而积累了很多经验。 在本文中,作者基于自己的经验(主要基于 TensorFlow)提出了一些训练神经网络的建议,还结合了案例,可以说是过来人的实践技巧了。

0

[转]知乎容器化构建系统Jenkins设计和实践

知乎选用 Jenkins 作为构建方案,因其强大和灵活,且有非常丰富的插件可供使用和扩展。早期,应用数量较少时,每个开发者都手动创建并维护着几个 Job,各自编写 Jenkins Job 的配置,以及手动触发构建。