看到这些题目忍不住转过来,觉得能把这些都完整解答,功力不是一般深厚了。有具体的coding、大量算法还有一些常用的基础知识和原理等。
转自微信公众号:程序猿石头,PC版链接:羡慕,又一清华学弟斩获 6 个大厂 SSP Offer | 面经分享。
看到这些题目忍不住转过来,觉得能把这些都完整解答,功力不是一般深厚了。有具体的coding、大量算法还有一些常用的基础知识和原理等。
转自微信公众号:程序猿石头,PC版链接:羡慕,又一清华学弟斩获 6 个大厂 SSP Offer | 面经分享。
HomeNAS上面虽然可以使用SFTP、WebDAV和NAS等协议分享文件,但是在易用性上面还是不如网盘的短连接+简单密码的方式好用。一直想找一个类似网盘的HTTP短连接分享的系统。EMBY的分享按钮似乎不能正常工作,更别谈使用带密码校验的功能了。之前Windows系统的Everything,只支持单个账户登录。
集中搜索了一下类网盘的解决方案,发现NextCloud、H5AI和FileRun都有类似功能,首先安装了NextCloud,发现其只能管理新上传的文件,所有文件必须进入了NextCloud的数据库才能被管理起来,NextCloud提供了命令行工具,扫描指定目录的所有文件和目录加入到其数据库中,但是每次目录有变化都需要重新扫描,不是太友好。直接放弃。
H5AI就没有尝试,主要发现该软件多年未更新。
最后FileRun,从软件的主页上面就看到了不需要导入文件的介绍:
使用docker镜像安装,网上其他资料都是介绍的使用docker-compose安装的,这里我本机已经有mysql的容器在运行了,因此直接使用docker run启动FileRun容器:
docker run -d \ --name filerun \ -p 8080:80 \ -v /opt/filerun/html:/var/www/html \ -v /media:/user-files \ -e FR_DB_HOST=yourdbhostip \ -e FR_DB_PORT=3306 \ -e FR_DB_NAME=filerun \ -e FR_DB_USER=filerun \ -e FR_DB_PASS='yourdbpasswrod' \ -e APACHE_RUN_USER=www-data \ -e APACHE_RUN_USER_ID=33 \ -e APACHE_RUN_GROUP=www-data \ -e APACHE_RUN_GROUP_ID=33 \ afian/filerun
其中/media是HomeNAS希望被管理的文件的根目录。使用superuser:superuser登录后,修改默认密码,完美呈现出media目录的所有文件。所有的文件相关操作均可在FileRun的WEB客户端上面操作。也能使用链接分享文件或者目录。访问分享链接的客户能在页面上一键打包下载所有文件,也能单个下载某个文件。
一直都习惯使用WindowsLiveWriter发日志,开启HTTPS后发现WindowsLiveWriter用不了,推测是WLW不支持HTTPS的原因。于是重新审视“.httpaccess”文件,最终使用如下配置支持全站HTTPS和WLW继续使用。
这个十一原定的计划取消了,没有做好备份计划,也就不打算出远门了,关在家里,把一直都想做的一个本地化的人脸识别服务整了一下。提供人脸分析的开源服务似乎很多年都没有大的变化了,一直都是Dlib和OpenCV,对比了一下,Dlib更容易使用。一直没有正经写过Python代码,翻出N年前买的Python编程书,边翻书Google、边写代码。基本的代码流程比较简单,Dlib官方也有例子,很容易运行起来,但是要服务化,要做人脸比对,并且是增量的人脸比对和识别,并不容易。说做就做,最终整个服务形成如下架构。
代码和部署使用方法在如下git工程:https://git.codefine.site:3000/Shentar/facerec
首先需要将探测的过的“人脸”存储起来,然后能输入一张人脸返回与该人脸近似的所有人脸,这样客户端好做人脸归集。很快做好了一个初步的框架:使用Flask提供REST接口接收照片,在响应中返回人脸的特征标识,使用SHA256对人脸68点位的描述向量进行HASH,返回给客户端。同时将HASH值和实际的token存储到Sqlite。第一天大概就完工了这个功能。
运行起来,发现单纯的Flask不能并发,第二个请求会报错,一次只能接受和处理一个请求。于是又按照网上的经验,使用Gunicorn和Gevent来做多线程的方案,因为习惯了单进程多线程的方式,多线程访问Sqlite需要加锁,按照通用的做法,使用一个队列来管理Sqlite实例。继续验证,发现多线程并不能加速Detect的效率,貌似Dlib不支持多线程加速。调整为多进程,四个CPU都能运用起来。
终于找到了一个能将这个3.2GHZ的四核CPU跑满的业务了 ^_^
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 39 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 94
Model name: Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz
人脸检测的效果还不错,错误率的话,自己家用是够了。特别是在侧脸检测上面,比较准确。在人脸比对方面,错误率就要高一些了,反复验证,发现0.36的比对阀值比较合适。侧脸虽然检测率高,但是在比对上面,只用通用的拟合范数,结果会表现为差异很大。因此这里应该是需要有定制化的比对实现,只做部分比对。这块需要深入到人脸检测技术内部,去分析128D的特征值向量的每一个值,短时间内没办法去研究透了。
由于采用了多进程,因此没法共用一个Sqlite运行时实例,强行并发读写访问会导致数据库错乱,不得不又做了一个服务来封装Sqlite,多个检测进程输出的人脸特征值都发给该服务来顺序存储,同时也返回给客户端。两个服务之间同样采用REST接口交互。
准备大规模上量,将jAlbum目前使用的线上人脸识别服务切换到这个本地服务上面,又发现检测时长非常高,一张4M的图片,大概需要几秒的时间,并且还有些非常小的区块被检测到了。对于检测慢的问题,考虑降低输入的照片的像素,图片减小后,长宽的像素点都相应减少了,但是人脸的特征点并不会损失太多。因此先对图片进行降低像素和尺寸,识别完成后,对识别到的人脸在照片上的位置也要相应做缩放,对比了一下,原始大小检测和缩放后检测,再对结果做相反的缩放,最终结果误差不大,但是这样能极大提速。对于非人脸和质量不高的人脸被检测到的问题,做了一些粗浅的限制,人脸长宽必须大于100的阀值才认为是正常的人脸。Dlib应该有正统的输出人脸的质量的参数,查了很久,没有找到合适的方法,就只能先这样吧。在比对方面,还有一些重要的概念,没有弄明白,如人脸对齐、年龄、性别检测等,不清楚我的代码里面是否已经有调用已经做了这块。
具体的处理代码:
data = np.frombuffer(data, np.uint8) if data is None: raise Exception('image is required.') zoom_ratio = 1 if data.size > 6 * 1024 * 1024: img = cv2.imdecode(data, cv2.IMREAD_REDUCED_COLOR_4) zoom_ratio = 4 elif data.size > 4 * 1024 * 124: img = cv2.imdecode(data, cv2.IMREAD_REDUCED_COLOR_2) zoom_ratio = 2 else: img = cv2.imdecode(data, cv2.IMREAD_COLOR) faces = [] dets = detector(img, 1)
总的来说,开源项目,适合做一下Demo,如果要尽善尽美,那么就要深入到源码,有针对性的去优化检测和比对模型。作为个人的实验和家用还是很不错的。至少在快速编程和服务化这方面。
本站用的Wordpress版本(4.8.2)有些老了。从主程序的代码记录来看上一次升级还是17年的事情,快三年了。
“自研”的相册管理程序,介绍和部署方法参考《jAlbum——Java WEB版相片管理系统 》。
国内访问github总是非常慢,所以把代码托管到HomeNas上面。使用gogs
接收各个终端上面备份的视频、照片文件。使用sync搭建,目前墙内无法访问该工具的官方网站。现在有开源免费的替代方案:Syncthing。
everything本来是一个Windows系统的本地文件搜索工具,以其高效而著称,在IT从业人员中使用非常广泛。其开放WEB访问方式,支持远程搜索和下载文件,远程办公时访问HomeServer上面的文件非常方便。遗憾的是,至今其都不支持HTTPS方式访问,并且用于认证的用户密码机制非常原始。可能是作者为了保持该软件的健壮和简单,不愿意加入更多的小众化功能。
媒体管理平台,支持各大平台部署Server端,支持众多的终端部署客户端应用。免费版本的客户端限制较多。当然网上也流传着各种破解方法。 在HomeServer上面部署Emby主要用于管理电视剧、小孩子看的动画片、无损音乐和超清电影,没有广告干扰的娱乐时光还是很惬意的:) 其中电影自动搜索字幕比较有用。但是对于非电影文件,按照电影去搜索元数据时,会出现匹配错乱的问题,因此非电影文件的库都是禁用自动更新元数据。
这年头,RSS源越来越少了,只能自行部署一个RSSHub,目前主要用这个工具的客户端快速提取正在访问的网页中的RSS Feed。服务端能起的作用似乎还有限,也可能是还没有完全整明白这个该怎么用。
在香港的一个主机提供商那里购买的丐版空间,只有1G的文件存储容量,博客中日积月累的各种图片和PDF已经将空间耗尽,还有Reader和博客的数据库文件其实也是分享的这1G的空间,而各大公由云的对象存储又收费,想着家里的NAS每天开机也是闲着,就再承担点负载。将网站的所有静态文件都从“自研”的托管服务上面出,模拟主流对象存储的API实现了类似镜像存储的机制。将所有图片本地保存。这样可以定期清理博客托管服务服务上面的图片和附件等。 当然还有最基本的NAS文件共享服务、远程访问服务、偶尔当梯子给其它终端代理、作为下载机等普通功能都不在话下。 不知不觉家里一个小小的Server上都部署了十来个服务。其实,HomeServer就缺了一个完整的80和443等端口,如果国内电信服务提供商开放这些端口,那么都不用购买任何网站托管服务了,直接在HomeServer上面运行所有网站相关的任务。这样不仅省钱,还便于管控。不过话也说回来,电信封了很多端口,对HomeServer的维护来说,也解决了网络安全的问题。
2020-8-9更新:增加WebDAV服务,使用go编写的caddy和webdav插件搭建。主要服务于跨平台的笔记服务:Joplin,除了界面不如印象笔记,功能上已经够用。有了WebDav,能做的事情就比较多了,如: 1、管理个人密码的keepass; 2、备份油猴配置和脚本; 3、当作网盘直接在桌面系统中挂载使用。
2020-8-27更新:增加cockpit服务,并替换自签名证书。
用于运行两个虚拟机: 一个是Win10系统:1、用于搭建科学上网的客户端,给其他设备提供代理服务,科学上网这块在Win生态下的工具远比Linux系列的丰富和易用。这样不用每个终端都安装各种工具,只需要配置代理指向该Win系统即可。2、安装迅雷,现在下载没有迅雷,啥资源都是Kbytes/s的速度,难以忍受,毋庸置疑,资源都已经被迅雷垄断了,迅雷充当了CDN的作用。 另外虚拟化了一个黑群晖,主要用于体验群晖系统,其实群晖能做的事情,在这个HomeNAS上面都有了,只是想体验一下群晖的易用性。惊奇的发现,在虚拟机里面虚拟化出来的磁盘(600GB),磁盘落在EXT4文件系统上面,然后再经过群晖的文件共享出来使用,这个共享跟NAS上面原来的共享在性能上面没有任何差异,甚至更稳定,写速率稳定在112MB/s,是不是经过Vmware和EXT4文件系统两级缓存之后,速度跟均衡。装一个空壳的宿主机,把所有硬盘都交给虚拟机的黑群晖管理,也不失为一种新的NAS玩法。
安装docker,并配置远程访问,dockerd监听本地端口,配置TLS证书。运行portainer,实现远程管理docker实例。运行wiz笔记程序,体验不同于joplin风格的为知笔记,该笔记在抓取网页方面有所欠缺,但是界面还有性能上面非常不错。
参考《基于Dlib、Flask和Sqlite的人脸检测和识别服务》。
可以将HomeNAS瞬间变网盘,主要用于解决文件分享、带校验码分享的场景。另外也可以用这个来直接通过页面操作远端文件的增、删、改、查。参考链接安装 FileRun,HomeNAS 秒变网盘
使用docker部署Grafana、普罗米修斯和Node-exporter监控服务器的磁盘、CPU、内存和网络等消耗。
部署图库服务,可以作为图床、相册等使用。简单高效管理图片。
一个界面非常友好,功能强大的多设备、多用户,跨网络同步的笔记服务。
参考《架设Tiny Tiny RSS(TTRSS)阅读器,找回Google Reader!》
运行各种新闻和电影BT下载爬虫程序。
安装基于Calibre的电子书在线阅读和管理服务:源码,Docker仓库,本站书库:代码人生
自托管的对象存储服务,兼容Amazon S3。安装指导:链接。
一个非常好用的临时文件共享服务,客户端和服务端均使用最简洁的HTTP请求上传下载文件。可在此试用本站的Transfer.sh服务:链接
非常好用的站点统计工具,Google Analytics的自建替代品,自建站点统计服务。对于Wordpress博客,甚至可以直接使用插件集成所有服务端的功能。
在线Office,可以完全替代本地的Office。官网的文档介绍太弱,安装过程中有一些坑,并且官方提供的镜像太臃肿,我做了少量精简。安装过程总结如下:《HomeServer安装在线Office:Docker安装最新精简版OnlyOffice》
在外网访问家里的NAS服务器上面的jAlbum相册时,使用HTTPS更安全。之前使用的一直是自签发的证书,在自己的手机上面导入了自签发证书的CA,因此浏览器一直显示安全的绿色。今天在其他手机上面使用HTTPS访问时,打不开页面,使用HTTP访问则没问题,很快就想到这是证书的问题,自签发证书的根证书没有安装。但是总不能每次有新的设备访问时就要求其安装CA证书,除非这个服务能做到像12306那么不可或缺(12306上线很多年都不购买商用证书,一直要求用户下载证书安装到本地,这种做法很危险)。
最近改了两个jAlbum的bug,问题并不复杂,但是比较有代表性。在这里记录一下。第一个问题是,在单张照片的页面提供了一个“隐藏”当前照片的按钮。当点击该按钮时,页面重新load,显示下一张照片,使用了当前照片的ID来构造下一张照片的url,即加载url:
/?next=[currentphotoid]&count=1,
具体到服务端接收这个请求时,需要使用当前照片的ID到数据库中索引下一张。
然后对当前照片发起删除操作,即使用ajax发起一个HTTP请求:
DELETE /photos/[currentphotoid]
向服务端发送一个delete请求,具体的浏览器端代码为:
CSDN极客,网址:http://geek.csdn.net/,经常有一些比较好的链接,对于程序员来说,有一些阅读学习价值。不知从何时开始该网站不再提供RSS订阅,这对于RSS重度使用者来说有点难以忍受。因此花了一下午时间做了一个抓取该网站头条主页内容生成RSS订阅地址的实现。使用PHP后台抓取网页内容,对内容进行正则匹配后过滤出有价值的链接,生成RSS XML格式文档后返回。订阅地址为:http://codefine.site/rss_factory?url=geek.csdn.net。同样,也给支持开发者头条(https://toutiao.io)新增了RSS源:http://codefine.site/rss_factory?url=toutiao.io。
订阅效果:
前一阵子遇到一个奇怪的问题,分析了很久,最后查阅了一些资料,找到了问题的原因,是TCP的backlog机制的原因。首先描述一下重现问题的现象和过程: 构建一个TCP的服务端,监听端口4321,只监听请求,不accept,客户端不断发起连接,观察TCP连接建立的情况。服务端程序代码如下: