iquery

问题： How can I query git to find out which branches contain a given commit? 如何查询git以找出包含给定提交的分支？ gitk will usually list the branches, unless there are too many, in which case it just says "many (38)" or something like that. gitk 通常会列出分支，除非有太多分支，在这种情况下，它只会显示“许多（38）”或类似内容。 I need to know the full list, or at least whether certain branches contain the commit. 我需要知道完整列表，或者至少要知道某些分支是否包含提交。 解决方案： 参考一： https://stackoom.com/question/5xJ9/如何列出包含给定提交的分支 参考二： https://oldbug.net/q/5xJ9/How-to-list-branches-that-contain-a-given-commit 来源： oschina 链接： https://my.oschina.net/u/4428122/blog/4314147

0x00 概述 此文力求比较详细的解释DNS可视化所能带来的场景意义，无论是运维、还是DNS安全。建议仔细看完下图之后的大篇文字段落，希望能引发您的一些思考。 在“F 5利用Elastic stack（ELK）进行应用数据挖掘系列（2）-DNS ”一文中阐述了通过DNS logging profile进行DNS可视化的一种方法。DNS logging profile本身对解析和响应是发出的两条日志，因此在上篇文章中我们其实用了一些特殊的方法来处理一些我们想要的场景。所以这样的处理方式可能不够灵活，也不够优雅。通过logstash根据Query ID进行日志聚合后再处理也是一种思路，但是日志聚合本身这个动作需要仔细处理以防止聚合出错。同时即便使用了聚合，由于DNS logging profile输出的内容是固定的，因此在灵活性上依旧差那么一些。这篇文章则给大家提供了另一外一种形式的可视化。从通用性角度来说，更建议使用本篇文章中的方法，不受BIGIP DNS(GTM)版本及模块license类型的影响。 0x01 方法思路 iRule通过HSL输出必要的解析日志数据至elk 0x02 Dashboard与可视图分析 在整个dashboard中，划分了这样几个功能区域： 最上面的解析来源地理热力图，可以清晰的看出哪些地方是热点解析区域。热点解析区域，结合DNS TTL参考

Weed3，微型ORM框架（支持：java sql，xml sql，annotation sql；template sql；事务；缓存；监听；等...） 05年时开发了第一代； 08年时开发了第二代，那时候进入互联网公司，对性能有了全新的认识； 14年时开发了第三代，因为不喜欢滥用反射，不喜欢有很多配置，所以一直在执着的没放弃。 前两代，都是在.net开发的；第三代，重点放在了java上。应该算是个功能全面且小巧的ORM框架：0.1mb，无其它依赖。对外的接口也不多，主要由DbContext上的四个接口发起所有的操作。 因为一些执念写的东西都算是比较微型的： Snack3（Json框架 70kb，有序列化，有Jsonpath，有格式转换机制；强调构建能力） Solon（Web框架 80kb） 一个手机浏览器（0.1mb，可是有完整功能哦；算是一个创意作品） Weed3 特点和理念： 高性能：两年前有个同事测过四个ORM框架，它是性能最好的（不知道现在是不是）。 跨平台：可以嵌入到JVM脚本引擎（js, groovy, lua, python, ruby）；也有.net，php版本。 很小巧：0.1Mb（且是功能完整，方案丰富；可极大简化数据库开发）。 有个性：不喜欢反射、不喜欢配置...（除了连接，不需要任何配置）。 其它的：支持缓存控制和跨数据库事务（算是分布式事务的一种吧）。

1、简介 关于并行Linq,Ms官方叫做并行语言集成(PLINQ)查询,其实本质就是Linq的多线程版本,常规的Linq是单线程的,也就是同步的过程处理完所有的查询.如果你的Linq查询足够简单,而且耗时短,那么建议你使用Linq,但是如果你的查询比较耗时,而且很复杂,且不涉及多线程争用问题,那么可以使用PLinq技术,让多个线程参与到查询中来,有效的利用CPU资源.这样你的代码能从中获得最大的收益.判断什么时候使用PLINQ,什么时候使用Linq?这需要你自己去实践,因为不同的环境,产生的效果不一样,因为我前面的随笔中介绍了,多线程(Task,因为Parallel是基于Task的)本身的开销,CPU的上下文切换,都是影响的因素.可能你使用PLINQ执行一个复杂的查询,本地的运行速度很快,但是放到服务器上去反而变慢了.所以使用还是需要慎重. 2、代码结构简介 (1)、基本Api介绍 那么如何使用PLINQ呢?所有的PLINQ的Api都在System.Linq.ParallelEnumerable类下面,Api几乎和Linq一样,因为内容太多,这里就不截图了.MS几乎将常规的LINQ所有的Api都实现了一个并行版本.所有的方法都是ParallelQuery<TSource>类型的扩展，如下: 所有如果你有一个常规集合需要进行并行查询,那么你需要将该集合转换成ParallelQuery