Brain Dumps

  Understanding the basic terms and parts of Azure Pipelines helps you further explore how it can help you deliver better code more efficiently and reliably. Agent When your build or deployment runs, the system begins one or more jobs. An agent is installable software that runs a build or deployment job. Artifact An artifact is a collection of files or packages published by a build. Artifacts are made available for the tasks, such as distribution or deployment. Build A build represents one execution of a pipeline. It collects the logs associated with running the steps and the test results. Continuous delivery Continuous delivery (CD) (also known as Continuous Deployment) is a process by which code is built, tested, and deployed to one or more test and production stages. Deploying and testing in multiple stages helps drive quality. Continuous integration systems produce deployable artifacts, which include infrastructure and apps. Automated release pipelines consum

  Business demands continuous delivery of value. Value is created only when a product is delivered to a satisfied customer. It's not created when one silo in the process is completed. It demands that you reset focus from silos to an end-to-end flow of value. The core idea is to create a repeatable, reliable, and incrementally-improving process for taking software from concept to customer. The goal is to enable a constant flow of changes into production via an automated software production line. Think of it as a pipeline. The pipeline breaks down the software delivery process into stages. Each stage aims to verify the quality of new features from a different angle to validate the new functionality and prevent errors from affecting your users. The pipeline should provide feedback to the team. Also, visibility into the changes flows to everyone involved in delivering the new feature(s). A delivery pipeline enables the flow of more minor changes more frequently, with a fo

  While one of the benefits of Git is its ability to hold long histories for repositories efficiently, there are times when you need to purge data. The most common situations are where you want to: Significantly reduce the size of a repository by removing history. Remove a large file that was accidentally uploaded. Remove a sensitive file that shouldn't have been uploaded. If you commit sensitive data (for example, password, key) to Git, it can be removed from history. Two tools are commonly used: git filter-repo tool The git filter-repo is a tool for rewriting history. Its core filter-repo contains a library for creating history rewriting tools. Users with specialized needs can quickly create entirely new history rewriting tools. Note More details are in the repository git-filter-repo . BFG Repo-Cleaner BFG Repo-Cleaner is a commonly used open-source tool for deleting or "fixing" content in repositories. It's easier to use than the git filter-

  The fork-based pull request workflow is popular with open-source projects because it allows anybody to contribute to a project. You don't need to be an existing contributor or write access to a project to offer your changes. This workflow isn't just for open source: forks also help support inner source workflows within your company. Before forks, you could contribute to a project-using Pull Requests. The workflow is simple enough: push a new branch up to your repository, open a pull request to get a code review from your team, and have Azure Repos evaluate your branch policies. You can click one button to merge your pull request into main and deploy when your code is approved. This workflow is great for working on your projects with your team. But what if you notice a simple bug in a different project within your company and you want to fix it yourself? What if you're going to add a feature to a project that you use, but another team develops? It's where f

  The quality of code shouldn't be measured subjectively. A developer-writing code would rate the quality of their code high, but that isn't a great way to measure code quality. Different teams may use different definitions based on context. Code that is considered high quality may mean one thing for an automotive developer. And it may mean another for a web application developer. The quality of the code is essential, as it impacts the overall software quality. A study on "Software Defect Origins and Removal Methods" found that individual programmers are less than 50% efficient at finding bugs in their software. And most forms of testing are only 35% efficient. It makes it difficult to determine quality. There are five key traits to measure for higher quality. Reliability Reliability measures the probability that a system will run without failure over a specific period of operation. It relates to the number of defects and availability of the software.

—— 独 唱 —— 周深：《大鱼》 . 阿云嘎：《生命的故乡》 . 余笛：《柔声倾诉》 . 王晰：《一生守候》 . 周深：《The Lonely Shepherd》 . 郑云龙：《生死对决》 . 王凯：《怀念战友》 . 阿云嘎：《希拉草原》 . 蔡程昱：《多么快乐的一天》 . 周深：《Memory》 . 郑云龙：《天边外》 . 仝卓：《九儿》 . 鞠红川：《可爱的一朵玫瑰花》 . 高天鹤：《玛依拉变奏曲》 . 马佳：《Che gelida manina》 （冰凉的小手） . 周深：《Time to say goodbye》 . 廖佳琳：《笑之歌》 . 郑云龙: 《就在这瞬间》 . 阿云嘎: 《心脏》 . 李文豹：《青花瓷》 . 张超：《无问》 . 王晰：《谁》 .   —— 二 重 唱 —— 王晰、周深：《月弯弯》 . 贾凡、陆宇鹏：《跟着你到天边》 . 阿云嘎、蔡程煜：《鹿 Be Free》 . 阿云嘎、贾凡：《生命的河》 . 阿云嘎、郑云龙：《剧院魅影》 . 郑云龙、廖佳林：《诗人的旅途》 . 余笛、洪之光：《故乡的云》 . 王凯、廖佳琳：《最终信仰》 . 王晰、郑云龙：《慢慢喜欢你》 . 王晰、高杨：《她真漂亮》 . 阿云嘎、郑云龙： 《I’ll cover you》 . 蔡程昱、郑云龙：《对不起我爱你》 . 阿云嘎、方书剑：《那个男人》 . 阿云嘎、王晰：《往日时光》 . 郑云龙、张超：《美女与野兽》 . 蔡程昱、马佳: 《旷世之爱》Grande Amore . 郑云龙、阿云嘎: 《我属于我自己》 . —— 三 重 唱 —— 王晰、鞠红川、李琦：《The sound of silence》 . 李文豹、南枫、星元：《小河淌水》 . 余笛、洪之光、龚子棋：《

  The forking workflow is fundamentally different than other popular Git workflows. Instead of using a single server-side repository to act as the "central" codebase, it gives every developer their server-side repository. It means that each contributor has two Git repositories: A private local. A public server-side. The forking workflow is most often seen in public open-source projects. The main advantage of the forking workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their server-side repositories, and only the project maintainer can push to the official repository. It allows the maintainer to accept commits from any developer without giving them written access to the official codebase. The forking workflow typically will be intended for merging into the original project maintainer's repository. The result is a distributed workflow that provides you a flexible way for

 大家可能都有过这样的经历：工作刚一会，一个隔壁组的同事ping你说有问题要问，你停下手里的活回答TA的问题。几番对话下来，问题解决了，30分钟也过去了。你继续手里的活儿，结果10分钟以后你的PM又来找你：“Hey, qq regarding the project X...”，你一想是一个quick question就再次停下工作开始回复人家。搞定以后你倒了一杯咖啡舒缓一下情绪，结果屁股还没坐热，你组里的new hire问你能不能打个quick call... 这样的事情每天都在发生，原本计划好的工作任务被一个又一个ping打断。我们不断停下手中的事情去处理别人的请求，这不但占用了我们大量的时间，我们的工作效率还因为不断的context切换受到了极大的影响。在这里，我想分享一下我的做法，希望能对大家有所帮助。 首先是心态的转变，即不要觉得没有马上回复消息是不好的。有人可能觉得别人找你就应该马上回复，不然就是不礼貌，而且别人会被block。我觉得其实不然。首先每个人的时间都很宝贵，因为忙碌无法及时回复消息是完完全全可以理解的。如果你能做到消息必回但不一定秒回，而且回答认真负责不敷衍，真正帮助别人解决问题，别人依然会对你有很好的印象。其次，大部分事情真的都不是那么急。如果真的很紧急，他们自然会escalate。而且相信我，很多时候同一个问题，他们问的人并不只有你一个。再次，你如果一直回复很快，会无意中抬高人家对你的期待值，一旦你有哪次没做到，别人反而可能会有意见。 当我们意识到消息可以不用马上回复时，我们就可以利用Calendar在固定时间回复消息了。我之前说过要尽量避免context切换，所以我们可以在每一阶段工作开始前或结束后统一回复消息。比如早上工作前，午饭后，下午下班前。这样每个阶段的间隔也就只有3个小时左右，当然如果你手头没有活，可以更早回复。这段时间可以用来处理简单的ad-hoc问题，比如要测试账号，文件链接，简单的技术问题，也可以用来review代码，design doc等等。如果是需要即时交流的问题，我们可以提前和对方沟通在日历上schedule一个会议来专门处理，这样做一来保证了不会打乱你事先计划好的工作，二来限定了时间。大家应该有过一个临时的“quick call”持续了一个小时才结束的情况吧。除此之外，我们还可以在日历上b

  9月27日，初秋，青岛海边的国际会议中心里，一场发布会，台下坐得满满当当。一个中年男子小跑上演讲台，引得一阵欢呼。来人身穿文化衫和休闲裤，气质温和，这个打扮走在街上，没人能知道他竟是个亿万富翁。 这是被字节收购 13 个月后，PICO 第一次以发布会的方式对外发声。带着新发的VR一体机 PICO 4，掌门人周宏伟指点江山，言说最新的VR行业趋势，却剑指字节十年后的未来。 周宏伟 而在一年前的北京办公室里，要向一起奋斗的兄弟们，公布PICO即将卖身字节的消息，周宏伟说到一半，难掩泪水，几近哽咽。 周宏伟这么一哭，下面不少人也湿了眼眶——PICO 的一个时代，就要这么终结了。 说到底，周宏伟并不想卖——6 载心血，一群兄弟，眼见着已经在国内拿下头名，不谈生意，也有感情。 再说，自己的孩子自己疼，PICO 对于周宏伟有天大，但对于字节，PICO 只是众多产品中的一个。进了字节，自己怎么办？兄弟们怎么办？2021年的周宏伟没有答案。 然而 PICO 要卖，几乎就是箭在弦上。不卖，远在美国的扎克伯格，不可能长期允许一家公司，一边代工 Oculus Quest 2，一边卖着自家的VR设备。 于情于理都说不过去，歌尔——PICO 的母公司——不如断尾求生，把 PICO 抛出，与 Meta 不伤和气，还能获得一笔不菲的现金。 没人想当那条断掉的尾巴，周宏伟亦然，即使下家是字节。 几年来，“财大气粗”的字节，精于运用“钞能力”，快速扩张自己在互联网领域的版图。 而买下PICO这事，本身就有点像是一次豪赌。 有意思的是，两年前，PICO早就寻求融资，估值15个亿，然而当时整个行业一片哀嚎，尽管PICO是当之无愧的头部，但还是无人问津，融资未果。 于是，PICO的重要话事人，歌尔老板姜龙，找到了青岛几个政府引导基金，搞定了这轮融资，也让PICO彻底甩开了3Glasses等一众对手。 所以，当最终字节以90亿的价格买下PICO，所有人都大跌眼镜。 有人告知雷峰网，是姜龙直接找到了字节的老大张一鸣。两个老大坐在桌前，大笔一挥，90亿元的交易爽快达成，相比 PICO之前的估值翻了6-7倍。 但更接近事实的版本是，Meta Oculus的成功引发了字节和腾讯两个巨头对PICO 的追逐，双方的不断抬价让PICO一年不到的时间里在基本面几乎没变化的前提下翻了六倍，最终字节笑到了最后。 但腾讯也没