ARTS 2019 06 30 (37)

Algorithm：153. 寻找旋转排序数组中的最小值
Review： 谨慎选择你的工具
Tip/Tech： 基于用户的协同过滤算法。
Share： 我不希望变成全栈开发者

Algorithm

153. 寻找旋转排序数组中的最小值

这里是个非常经典的旋转的数组的题目，如果用时间复杂度为$O(N)$， 那做法会很简单，但是这题的定位是中等。肯定不会这么简单的啦。
题目理解就是在一个数组中寻找一个数字，那么就很容易想到了，就是用二分查找法。
其实最后重要就是二分查找要确定一个跳出循环的条件，这里的跳出的条件就是，前一个元素比后一个元素小，那么后一个元素无疑就是最小的元素。
因为只有旋转的起点是最小的节点，所以以上的条件是很容易确认的。
那么难点就来了，就是你要怎么确定要去左边还是去右边查找这元素？
重点是确定问题：就是连续递增序列到哪为止？如果你确定了后一个元素比你大，那么连续的递增序列该如何确定？
那么就是如果 中点元素比左边的元素大，那么就是递增的序列是从左边元素一直到中点元素，那么就是，因为左边的是连续的递增序列，那么最小的元素会出现在右边。
如果重点元素比右边的元素小，那么就是中点到右边的元素都是递增序列，那么最小的元素会出现在左边。
如果上面这么说明有些抽象的话，我们来看看代码：

Show the Code.

public int findMin(int[] nums) {
    if (nums == null || nums.length == 0) {
         return -1;
     }
     int left = 0;
     int right = nums.length - 1;
// 因为有可能移动了0个元素，所以有可能第一个元素就是最小的元素，所以初始化我们用第一个元素。
     int minIndex = left;
     while (nums[left] > nums[right]) {
         int mid = left + ((right - left) >> 1);
         if (nums[mid] > nums[mid + 1]) {
             minIndex = mid + 1;
             break;
         } else {
         //中点元素比左边的元素大，那么就是递增的序列是从左边元素一直到中点元素
             if (nums[mid] > nums [left]) {
                left = mid;
        // 如果重点元素比右边的元素小，那么就是中点到右边的元素都是递增序列，
             } else if (nums[mid] < nums[right]) {
             // 那么最小的元素会出现在左边。
                 right = mid;
             }
         }
     }
     //
     return nums[minIndex];
}

以上的时间复杂度就是$O(logN)$，这样就是这题的最好的解法了。

Review

Choose Your Tools with Care

谨慎选择你的工具

https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/thing_10/

现代应用程序很少从头开始构建。它们使用现有工具（组件，库和框架）进行组装

那么利用工具的时候我们需要注意什么的？

1. 不同的工具可能依赖于关于其上下文的不同假设，注意你的业务场景，没有一个框架或者工具是适配全部场景的。
2. 不同的工具有不同的生命周期，升级其中一个可能会成为一项非常困难和耗时的任务，因为新功能，设计更改甚至错误修复可能会导致与其他工具不兼容。
3. 某些工具需要相当多的配置，通常是通过一个或多个XML文件，这些文件可能会非常快速地失控。配置复杂性将使应用程序难以维护和扩展。 比如Spring？这里说的这种框架的配置的繁琐。
4. 如果您打算使用免费软件，您可能会发现毕竟它不是那么自由。您可能需要购买商业支持，这不一定是便宜的。
5. 许可条款很重要，即使对于免费软件也是如此。

Tip/Tech

推荐算法：基于用户的协同过滤算法。
基于用户的协同过滤算法主要包括两个步骤。
(1) 找到和目标用户兴趣相似的用户集合。
(2) 找到这个集合中的用户喜欢的，且目标用户没有听说过的物品推荐给目标用户。

Share

I don’t want to be a full-fullstack developer

我不希望变成全栈开发者。

https://artur-martsinkovskyi.github.io//2019/i-dont-want-to-be-fullstack/

更广泛还是更深？
不要误解我的意思，我认为扩大知识领域并理解你周围的部分以便更好地完成你的部分是好的，但让开发人员会精通所有的技术直接影响代码质量，选择解决方案和项目的未来发展。我们头脑中的空间是有限的。我们可以用更深入和更好的一个或几个领域的知识来填补它，或者开始在众多领域中咀嚼信息，从而导致对一切事物的肤浅知识。
并非所有剪辑都同样健康
Fullstack很有趣，因为它似乎几乎是软件工程领域独有的。**其他领域大多有分工，你不希望牙医治愈你的心脏和神经外科医生来修复你的痔疮。**它被用于软件工程的原因似乎是该领域的虚拟和故障安全性质的事实。

我们得到的平庸解决方案由那些在特定领域没有足够专业知识的人创建，以便看到更好的方?式，其中包含Stackoverflow答案和复制粘贴的粗略知识。

从短期经济角度来看，Fullstack可能是值得的，但它对整个行业和我们建立的项目都是有害的。