Linux中病毒后的处理过程
· ☕ 1 分钟 · ✍️ starifly
之前一台 centos 虚拟机中毒,导致CPU飙升,这里记录下处理过程。 查找可疑进程 执行命令ll /proc/ID/exe,通过进程ID确定其执行路径,先删

Git的撤销更改
· ☕ 3 分钟 · ✍️ starifly

前文《 Git基本操作》介绍了Git的基本概念和一些基本操作。

本文将介绍Git四个阶段的撤销更改:

  • 工作区的代码撤销
  • add到暂存区的代码想撤销
  • 提交到本地仓库的代码想撤销
  • 推送到远程仓库的代码想撤销

Git基本操作
· ☕ 6 分钟 · ✍️ starifly


一个“蝇量级” C 语言协程库
· ☕ 14 分钟 · ✍️ starifly
协程 (coroutine) 顾名思义就是“协作的例程”(co-operative routines)。跟具有操作系统概念的线程不一样,协程是在用户空间利用程序语言的语法语义就能实现逻辑上类似多任务的编程技巧。

Git分支管理
· ☕ 7 分钟 · ✍️ starifly
git的分支管理十分强大,本文主要涉及git中分支的查看和最基本的分支管理操作,主要包括分支的创建、切换、合并、衍合以及分支的推送和拉取等。

Learning Something
· ☕ 1 分钟 · ✍️ starifly
Learning How to Learn 关于编程的练习方法——读《刻意练习》有感 《如何阅读一本书》阅读笔记 工作流 笔记:有关开源项目 有一种焦虑叫:什么都想学,但什么都学不会 你

git add -A 和 git add . 的区别
· ☕ 1 分钟 · ✍️ starifly

git add -A、git add .和git add -u在功能上看似相近,但是有细微的差别,而且功能会随着git版本的不同而不同。


Vim Tips
· ☕ 3 分钟 · ✍️ starifly

Vim Tips.


关于 Markdown 的一些奇技淫巧
· ☕ 4 分钟 · ✍️ 码志

自从几年前开始在 GitHub 玩耍,接触到 Markdown 之后,就一发不可收拾,在各种文档编辑上,有条件用 Markdown 的尽量用,不能用的创造条件也要用——README、博客、公众号、接口文档等等全都是,比如当前这篇文章就是用 Markdown 编辑而成。

这几年也发现越来越多的网站和程序提供了对 Markdown 的支持,从最初接触的 GitHub、Jekyll,到简书、掘金、CSDN 等等,由此也从别人做得好的文档中,学到了一些『奇技淫巧』,所以本文不是对 Markdown 基础语法的介绍,而是一些相对高级、能将 Markdown 玩出更多花样的小技巧。

注:如下技巧大多是利用 Markdown 兼容部分 HTML 标签的特性来完成,不一定在所有网站和软件里都完全支持,主要以 GitHub 支持为准。


Ubuntu 使用笔记
· ☕ 2 分钟 · ✍️ 码志

使用 Ubuntu 过程中遇到的问题及解决方案。


持续集成教程 1 通识科普
· ☕ 2 分钟 · ✍️ ice1000

本教程系列将以 Travis CI 为主,我也不知道以后会不会讲 AppVeyor ,我也不知道以后会不会讲 Circle CI 和 CodeShip 。
这篇文章你可以把它当成一个索引,我给出了使用 Travis 需要阅读的内容,读者可以根据自己的需求选择阅读文档的特定部分。

CI 能做啥

  • 能帮你在云端自动编译项目
  • 每次你推送代码就会触发编译
  • 可以保留编译生成的目标文件
  • 自动上传 release
  • 编译失败发邮件提醒你
  • 编译失败发 Slack 消息提醒你

等等功能(这些都是最基本的)

混开源社区的 friends 喜欢使用一些现有的 CI 服务,比如 Travis, AppVeyor, Circle CI, CodeShip 等,
公司企业喜欢自己写 CI 自己用,因为这本来就是个高度定制的东西,要是你能提供高度定制的环境(比如装好了依赖的服务器)
当然做 CI 就超级简单了。

但是我们是混开源社区的 friends ,所以没有这种操作,首选当然是 Travis CI 。

理由: Linux + 自动部署


可移植的 Makefile 教程
· ☕ 12 分钟 · ✍️ liuchengxu

在我写 Makefile 的头 10 年里,我养成了一个非常不好的习惯

– 完全严格使用 GNU Make 的扩展名。过去我并不知道, GNU Make 与 POSIX 所保证的可移植特性之间的区别与联系。通常情况,它并不十分重要,但是当在非 Linux 系统上进行构建时,比如在各种 BSD 系统上,就会变成一件麻烦事儿。我不得不指定安装 GNU Make,然后在心里记住不要使用系统自带的 make ,而是使用 gmake 这样的工具来调用它。

我已经对 make 官方规范 十分熟悉,并且在过去的一年,我都在严格要求自己编写可移植的 Makefile。现在,我的构建不仅可以在各种类 unix 的系统之间进行移植,而且 Makefile 看起来更清晰与健壮。许多常见的 make 扩展名 – 尤其是条件判断 – 会导致不够健壮的却又复杂的 Makefile, 因此最好避免这些情况。能够确信你的构建系统能够各司其职,正常工作是非常重要的。

本指南不仅适用于之前从来没有写过 Makefile 的 make 初学者,同样适用于想要学习如何写出可移植 Makefile 的资深开发者。 但不管怎样,为了能够理解文中的示例,你必须首先对命令行(编译器,链接器,目标文件等等)构建程序的常规步骤十分熟悉。我不会建议使用任何花哨的技巧,也不会提供任何标准的初学者模板。当项目不大的时候,Makefile 应该是相当的简单,并且随着项目的成长,以一种可预见,清晰的方式不断丰富。

我不会覆盖 make 的每一个特性。如果想要学习所有完整的内容,你需要自行阅读它的规范。本指南将会详细讨论一些重要特性和约定俗成的规定。遵守已有的约定是非常重要的,这样使用你的 Makefile 的其他人,才能知道它能够完成和如何完成一些基本的任务。

如果你的系统是 Debian, 或是基于 Debian 的系统,比如 Ubuntu,bmakefreebsd-buildutils 包将会分别提供 bmakefmake 程序。这些可供选择的 make 实现,对于测试 Makefile 的可移植性十分有用,尤其是当你不小心使用了 GNU Make 的特性。虽然每个实现都实现了与 GNU Make 完全相同的一些扩展,但是它会捕获一些常见的错误。



点击屏幕右上角的 ···
在弹出的窗口中选择 在浏览器中打开