我的编程ARTS记录

开篇文章,记录一下我每周的 ARTS 和 技术规划

之后整理一下,把 ARTS 放到 Github

ARTS

Algorithm: 每周至少做一个算法题

Review: 阅读并点评至少一篇英文技术文章

Tip: 学习至少一个技术技巧

Share: 分享一篇有观点和思考的技术文章

关于 S 的补充:

主要是用训练“价值观输出”。

如果你想要有影响力,就要学会输出观点,输出观点,就会有人同意,有人不同意,甚至还会被骂,但是,有观点的信息交换会让人更巨烈的思考,成长的更快。

第一周 2018/06/18-06/24

Algorithm 算法题收获:

我做的 leetcode 第一道题 two-sum

开始我用 for 循环实现的,时间太长,之后看了一下解析,用 hash 表又实现了一次。

相比两次的 for 循环遍历,哈希表能够更有效的检查数组中是否存在目标元素。

保持数组中的每个元素与其索引相互对应的最好方法是什么?哈希表。

Review

A Language for the Next 10 Years

我们公司部分应用在使用 elixir 开发,我自己也写过一点 elixir 的项目,我对使用它一点基本的认识是 elixirruby 有些类似,有完善的工具生态,能够快速开发应用,是一门可读性良好,优雅,函数式编程语言。

但是对于文章介绍的高并发、出色的 Erlang VM、基于宏命令的元编程等等特性,我都没有实践过,没有发言权。

我觉的 elixir 会有它擅长的场景,会有它的市场份额,但并不会像 Java 那么火爆。

Tip

本周写 css 的时候,发现父元素为 display: flex;span 标签,自动具有了 inline-block 的属性。尝试找了一下规范。

可以在 Google 里这样定位 css 规范里的内容

site:w3.org flex

这一段指出部分在 flex 布局里会失效的属性

vertical-alignfloatclear ::first-line::first-letter

原因是这些属性是专门为 block 布局设计的。

Share

Elixir: 编程语言的未来

Comparing Elixir and Go

参照皓叔在 GO语言、DOCKER 和新技术 对新技术的评判标准,评价一下 elixir

一个技术能不能发展起来的三个关键技术点

  • 有没有一个好的社区
    类似 ruby,社区还不错

  • 有没有一个工业化的标准
    No

  • 有没有一个或者多个杀手级应用
    No

其他的因素

  • 学习曲线是否低,上手是否快

    并不像类 C 语言一样,语法还是有点特色。elixir 文档

  • 有没有一个不错的提高开发效率的开发框架

    有。Phoenix 完善的工具链以及功能齐全的 lib

  • 是否有一个或者多个巨型的技术公司作为后盾

    没有。只是 PinterestWhatsAppSlackAdobe 等公司部分场景在使用。https://elixir-companies.com/

  • 有没有解决软件开发中的痛点

    基于 ErlangOTP 提高了容错的、高可用的、并发的分布式系统的开发效率

总结一下,我觉的 Elixir/Erlang 适合于需要持续运行,并且尽可能持续提供服务的系统。elixir 不会像 Java 那么火爆,但是在某些领域,也会成为开发者一种不错的选择。

本周的技术计划

✅ 1、看完《算法图解》第一章
✅ 2、阅读深入浅出 react 和 redux 技术栈 前四章
✅ 3、完成小习惯的基本功能(不包含用户检测)

《算法图解》的收获

1、使用两种方法尝试写了一个二分查找
2、理解二分查找的需要的步数是 ${log_2 n}$
3、大O表示法:表示算法的速度有多快。

大O表示法指的并非以秒为单位的速度,它指出了算法运行时间的增速和最糟情况下的运行时间

4、一些常见的大O运行时间

下面按从快到慢的顺序列出了你经常会遇到的5种大O运行时间

  • O(log n),也叫对数时间,这样的算法包括二分查找。
  • O(n),也叫线性时间,这样的算法包括简单查找。
  • O(n * log n),这样的算法包括快速排序——一种速度较快的排序算法。
  • O(n2),这样的算法包括选择排序——一种速度较慢的排序算法。
  • O(n!),这样的算法包括旅行商问题的解决方案——一种非常慢的算法。

截取自《图解算法》截取自《图解算法》

小结

  • 算法的速度指的并非时间,而是操作数的增速。
  • 算法运行时间并不以秒为单位。
  • 谈论算法的速度时,我们说的是随着输入的增加,其运行时间将以什么样的速度增加。
  • 算法运行时间是从其增速的角度度量的。
  • 算法的运行时间用大O表示法表示。
  • O(log n)O(n) 快,当需要搜索的元素越多时,前者比后者快得越多。
  • 二分查找的速度比简单查找快得多。

第二周 2018/06/25-07/01

本周的技术计划

✅ 1、图解算法 看完第二章 🍻 第三章
✅ 2、研究 UI 自动化
✅ 3、深入浅出 react 和 redux 第5、6 章
4、git rebase

《图解算法》 第二、三章收获

数组和链表的对比

数组支持随机访问,读取速度快, 而插入速度慢;链表只支持顺序访问,读取速度慢,而插入速度快。

操作 数组 链表
读取 O(1) O(n)
插入 O(n) O(1)
删除 O(n) O(1)

O(n) = 线性时间
O(1) = 常量时间

数组插入元素为什么是 O(n), 比如考虑在数组的首位插入元素

我们可以分别运用双方的长处

使用数组存储 26 字母对应的链表,链表里存储以该字母开头的用户名。插入和删除的速度,使用了链表的长处,查询上使用了数组的长处,优化了时间。

⚠️ 只是个例子,实际运用中,有更好的方法。

选择排序

遍历数组,寻找最大的(或者最小的)把获取到的值存到另一个数组中,重复执行上面的操作 $O(n^2)$

递归

编写递归函数时,必须告诉它何时停止递归。每个递归函数都有两部分: 基线条件(base case)和递归条件(recursive case)。

递归条件指的是函数调用自己,而基线条件则指的是函数不再调用自己,从而避免形成无限循环。

使用栈虽然很方便,但是也要付出代价: 存储详尽的信息可能占用大量的内存。

每个函数调用都要占用一定的内存,如果栈很高,就意味着计算机存储了大量函数调用的信息。在这种情况下,两种选择。

  • 重新编写代码,转而使用循环。递归不一定,更快。只是更优雅。
  • 使用尾递归。不是所有语言都支持

第三周 2018/07/02-07/08

本周的技术计划

1、图解算法 看完第四章
2、git rebase
3、react 7 8 章

感谢您的阅读。 🙏 关于转载请看这里