本篇文章给大家谈谈bitbucket api，以及bitbucket api 接口对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

本文目录

产品经理必懂的技术那点事儿怎么样 好不好python configparser怎么写defaulthive与hbase的十大区别与联系利用BitBucket API 获取 [commit/branch/pullrequest] diffcentos7怎么安装ShengBTe产品经理必懂的技术那点事儿怎么样 好不好作者：herock

链接：https://www.zhihu.com/question/19554113/answer/14831116

来源：知乎

著作权归作者所有，转载请联系作者获得授权。

最近七年，我都在做互联网产品，其中前五年分别在创业公司和上市公司里，做别人的产品；近两年在创业，做自己的产品。

我的体会是：产品经理需要懂技术，创业者尤其需要。但前提是你总觉得有股憋不住的想要做点儿什么的冲动，如果打算混安稳日子，特别是在大公司，你什么都不需要懂，反而要小心别“知道的太多了”，傻人一生平安。

做产品这几年，和开发工程师打交道最多，和他们交流通常有两大忌：

一.忌不懂技术

更准确的说，是不能缺乏设计、开发一个互联网产品基本的技术常识，比如至少要清楚一个网站从不存在到能被用户访问，需要哪些必须的环节；也要明白一个App从你的脑海走到用户的手机里，需要经历怎样的过程。

有常识，当然不一定就能做出好产品，但没常识，就很象在村里呆了半辈子的人乍到城市，一举一动即使小心翼翼，也没法儿不透着突兀和不和谐。

很多公司都有完全不懂技术的产品人，大多年龄较长，也许是互联网出现的时候，他们已经过了充满好奇和渴望未知的年龄，不愿意放低身段去学习新东西，喜欢只凭着想象和自己的生活经验就开喷，间或以若干近期热门关键词作为点缀，以示自己尚蹲在潮流尖端。

这样的人也许能忽悠某些领导，但一定不招工程师待见，他们可能什么都不说，但心里已经开始等着看笑话，交给他们的开发需求，自然也是能拖则拖、能蒙则蒙。

二.忌懂技术

我遇到不少工程师喜欢说：“只要产品需求明确，技术上一切都能实现。”

这句话听起来相当豪迈，也让产品经理大为放心，觉得技术真是产品的坚强后盾。但其实传递了一个特别糟糕的信号。

当工程师这么说的时候，潜台词是：“你弄好你自己的事儿就行了，别来管我！”而且这种说法隐含着一个乐观但显然并不现实的假设：技术是无所不能的，他（掌握技术的人）也象灯神一样，可以实现你的任何愿望，只要你能明确的描述它。

我不知道阿拉丁说完愿望之后，假如胆敢继续追问灯神将具体采用何种技术方案来实现的话，会不会被塞到灯里，但我知道很多工程师在发现你关注技术层面过深的时候，都会有种领地被侵犯的感觉。

这就是工程师维护自己专业槽的本能，与行业中其它角色相比，工程师地位不是最高，待遇也不是最好，还经常加班加的要死要活的，唯一得天独厚的优势，就是专业槽比任何角色都深。关于产品、关于UI、甚至关于商业模式每个从业人员都能喷上几句，要是说到用户体验，那更是连业外人士都敢大喷特喷而没有任何心理负担：反正我就是用户嘛，越傻越光荣。而一旦涉及到代码，大多数人就直接晕菜了。想想那些UI设计师的苦逼段子，工作时没有喷子们指手划脚的干扰，真是上帝赋予工程师独有的恩赐。

所以当他们认为有外人正试图跨越这条槽时，自然会有所警惕，甚至体现出抵制和敌意。当一个产品经理发现工程师开始比较密集的使用术语或拼命把简单问题往复杂了说，你应该知道，他们在槽边开始向你射箭了。

从整个产品乃至公司的角度来说，各个专业角色之间的专业槽都是应该被填平的，产品经理不该对工程师玩挟天子以令诸侯，不要总假装自己是用户的三个代表，动不动就拿想象中的“用户需求”当“奉天承运”来用；工程师也不必总装灯神，假装无所不能很累的，工程师之间必有能力高下之分，其实有时候功能做不了或做不好，纯粹只是因为工程师能力所限。如果彼此坦诚一些，大可以提前有效沟通，尽可能避开那些投入产出比过低的部分，有不少工程师不愿意拿出来讨论的技术实现上的细节，都是值得产品经理参与进来的，在这些细节上如何取舍与抉择，会对产品的开发进度、性能甚至功能带来极大的影响，如果沟通到位，往往可以让开发工程师少做大量无用功。在我开始自己动手写代码之后，对这一点有了越来越深的体会。

下面就说说我为什么开始学写代码，算是回答问题的后半部分吧。

在我做互联网产品的前五年里，我对技术的了解仅维持在常识范畴，能够手写的代码只有html和css，连js都不会，更别提任何适用于Web开发的编程语言了。我一直认为自己无法完全亲手写一个哪怕是最简单的动态网站，是作为互联网产品人员，很大的缺陷和耻辱。

工程师们一般倒不这么觉得，和他们聊天的时候，有时顺嘴喷一些对技术架构或某些技术问题的看法，立刻遭到赞扬：“你很懂技术嘛！”这时马上打着哈哈说：“懂个p啊，我连helloworld都不会写，完全是纸上谈兵。”于是嬉笑声中，一群人把手里的箭收起来了。

但我压根儿就TM不想只能纸上谈兵，2009年，我不顾当时三十二岁的高龄，悍然决定要学Ruby，买了书、装好环境开始看书，敲代码，坚持了几天，然后失败了，考虑到也许Ruby对我来说太难，又尝试了Python，结果还是失败了。消沉几天后不死心，又买了一本iPhone开发的书，还趁机决定买了台27寸的iMac，但悲剧是只翻了翻书，连Xcode都没敢下就直接放弃了，这书上什么都不讲的啊！上来就是大段大段的代码啊！而且obj-c的代码都巨长，完全看不懂。

后来我想，这件事有两个收获：一.发现了自己智商的边界。二.我有了一台iMac。

转眼又过了一年多，想要自己动手做一个iPhone上的App的感觉越来越强烈，快压抑不住了。于是在某一天，我好了伤疤忘了疼似的把那本几乎没有折痕的iPhone开发基础教程又翻出来，等待Xcode下载的过程中，暗下决心：看不懂我也把它背下来。

后来发现笨办法至少对我来说，还挺管用的：照着书敲代码，能正常运行的话，就合上书，再敲一遍。一般重复四五次就能记得很牢了。合着书，劈里啪啦熟练的敲着自己还不知道是什么意思的代码，加上Xcode的自动补全很给力，几分钟就可以折腾出一大屏花花绿绿的代码，而且还能在iPhone上运行，这时会产生一种已经会写iPhoneApp的错觉，很奇妙。

人的大脑也很奇妙，你如果已经背下来了，本来不理解的就会慢慢自动理解，就这样背了一段又一段代码之后，突然发现：我明白是怎么回事儿了。之后就开始给自己提出各种小的不能再小的功能需求，尝试用这些代码去实现，每实现一个，都欣喜若狂：我能显示按钮了！我能弹出对话框了！我能写滚动列表了！我能发一条推送信息了！⋯⋯

这些事儿在熟练之后，也许就像喝口水一样平淡，但却能给初学者带来巨大的快乐，我一直觉得，能否始终保持如初学者般的热情、专注，决定了在做某件事时能走多远，能做多好。

由于书上所用的Xcode版本问题和我用的不同以及一些印刷错误，书上的代码不会总是百分之百能运行，有时会报错，只能上网用尽一切办法搜，搜索的过程中，就会慢慢看到一些专门的技术论坛、Blog，最终不可避免的会发现StackOverflow这个神奇的网站，你遇到的大部分问题，都能在上面找到答案。

当实现书上的功能已经不能带来狂喜的时候，就会忍不住想把自己束缚了很久的各种idea放出来了，终于可以亲手去做它，而不是局限在画画原型图、写写需求说明最后还要虔诚的擦拭神灯，呼唤灯神们显灵这样隔靴搔痒的做产品。

开发的过程对我来说充满了乐趣，因为写代码的时候，世界变的简单而美好，某个做法对还是错，你不需要自己反复猜测，也不需要和任何人没完没了争辩，编译器就是神圣的裁判。你的每个操作都能得到及时、明确的反馈，而且拥有近乎奢侈的试错机会，从这个角度来看，编程的乐趣倒是有点儿象玩游戏。

当然也会遇到无数的问题，StackOverflow、Github、Bitbucket、mailinglist会慢慢成为你的朋友。

在能够独自写出一个iPhoneApp并把它放到AppStore上之后，我又发现还需要再学一门语言，用来开发网站以及需要在App中调用的RESTfulWebService，于是不顾三十五岁的高龄，再一次悍然打起了Python的主意，有了学obj-c的经验，知道关键是要能狠得下心和静得下心来，看什么书，其实区别不是特别大，所以我就用了免费的LearnPythonTheHardWay，用前面提到的方法，跟着做了一遍（前半部分比较简单，可以每天做上十几个exercise，后面速度可能会慢一点儿），了解了Python怎么写之后，马上开始看DjangoBook2.0，只看到第九章，就等不及用同样的方法把DjangoTutorial做了两遍，接着惊喜的发现已经可以写一个简单但完整的网站了。然后很快试着用Django写了一个特别小的针对某垂直领域的工具类网站，上线跑了一段时间，昨天晚上结束免费试用，开始收费，现在看到已有几个付费用户，我很欣慰。

至于技术需要懂到什么程度，我觉得要是花几个月学的东西就够用一辈子，这买卖也太划算了，尤其是在技术领域，一定会需要持续学习，但对于我来说，已经没有资格象十几二十岁的年轻人那样仅凭兴趣广泛的学，我目前对这件事的原则非常功利：马上要用到的，能显著提高效率或者公认是最佳实践的就学，否则就先不学，尽量不折腾、严格控制投入的时间和精力。

比如写好的代码放到Server上，虽然只要能跑就算是部署成功了，但公认的最佳实践是使用virtualenv隔离Python环境，这样可以减少以后很多的麻烦，那就值得多花时间去了解，去应用；使用Fabric配合Git进行自动化部署可以大大提高效率，那就也值得花时间去学怎么用。

我也知道可以用Memcached或Redis来做缓存，提高应用性能；或是用RabbitMq和Celery来做异步队列，可以改善同步执行耗时较久的任务给用户带来的不爽感；还有Node.js似乎比传统的Web开发语言更适合做RESTfulAPI⋯⋯不过这些都不是目前最紧迫的问题，所以虽然我还不会而且确定会有用，但先不去学。

一没留神，喷了几千字，还是打住吧，看来中年男人的啰嗦算是没救了。

最后还是总结一下，就一句啊：

产品经理懂技术＝流氓会武术。你要是觉得帮派够大，自己脑子又好用到可以当师爷，那不会武术也凑合；要不巧是个和我一样没什么团队精神，又老喜欢独来独往的流氓，还想只凭着脑子就能连点儿防身术都不练，恐怕很容易被人打成爬行动物。

比较严肃的总结是：产品经理懂技术，在没资源的时候可以用最低成本把事儿办了，有资源的时候可以把资源用的更有效率。

python configparser怎么写default以这个非常简单的典型配置文件为例:

[DEFAULT]ServerAliveInterval=45Compression=yesCompressionLevel=9ForwardX11=yes[bitbucket.org]User=hg[topsecret.server.com]Port=50022ForwardX11=no123456789101112

1、configparser操作跟dict类似，在数据存取方法基本一致

>>importconfigparser>>>config=configparser.ConfigParser()>>>config.sections()

[]>>>config.read('example.ini')

['example.ini']>>>config.sections()

['bitbucket.org','topsecret.server.com']>>>'bitbucket.org'inconfigTrue>>>'bytebong.com'inconfigFalse>>>config['bitbucket.org']['User']'hg'>>>config['DEFAULT']['Compression']'yes'>>>topsecret=config['topsecret.server.com']>>>topsecret['ForwardX11']'no'>>>topsecret['Port']'50022'>>>forkeyinconfig['bitbucket.org']:print(key)

...

user

compressionlevel

serveraliveinterval

compression

forwardx11>>>config['bitbucket.org']['ForwardX11']'yes'123456789101112131415161718192021222324252627282930

2、默认配置项[DEFAULT]section的默认参数会作用于其他Sections

3、数据类型

configparsers不会猜测或自动分析识别config.ini参数的数据类型，都会按照字符串类型存储，如果需要读取为其他数据类型，需要自定义转换。

特殊bool值：对于常见的布尔值’yes’/’no’,‘on’/’off’,‘true’/’false’和‘1’/’0’，提供了getboolean()方法。

4、获取参数值方法get()

使用get()方法获取每一参数项的配置值。

如果一般Sections中参数在[DEFAULT]中也有设置，则get（）到位[DEFAULT]中的参数值。

5、参数分隔符可以使用‘=’或‘：’（默认）

6、可以使用‘#’或‘；’（默认）添加备注或说明

[SimpleValues]

key=value

spacesinkeys=allowed

spacesinvalues=allowedaswell

spacesaroundthedelimiter=obviously

youcanalsouse:todelimitkeysfromvalues

[AllValuesAreStrings]

valueslikethis:1000000orthis:3.14159265359aretheytreatedasnumbers?:no

integers,floatsandbooleansareheldas:strings

canusetheAPItogetconvertedvaluesdirectly:true[MultilineValues]

chorus:I'malumberjack,andI'mokay

IsleepallnightandIworkallday[NoValues]

key_without_value

emptystringvaluehere=

[Youcanusecomments]#likethis;orthis#Bydefaultonlyinanemptyline.#Inlinecommentscanbeharmfulbecausetheypreventusers#fromusingthedelimitingcharactersaspartsofvalues.#Thatbeingsaid,thiscanbecustomized.

[SectionsCanBeIndented]

can_values_be_as_well=True

does_that_mean_anything_special=False

purpose=formattingforreadability

multiline_values=are

handledjustfineas

longastheyareindented

deeperthanthefirstlineofavalue#DidImentionwecanindentcomments,too?1234567891011121314151617181920212223242526272829303132333435363738394041

7、写配置

常见做法：

config.write(open（'example.ini','w'）)1

合理做法：

withopen('example.ini','w')asconfigfile:

config.write(configfile)12

注意要点：

ConfigParser在get时会自动过滤掉‘#’或‘;’注释的行（内容）;

一般情况下我们手工会把配置中的暂时不需要的用‘#’注释,问题在于，Configparser在wirte的时候同fileobject行为一致，如果将注释’#’的配置经过get后，再wirte到conf,那么’#’的配置就会丢失。

那么就需要一个策略或规则，配置需不需要手工编辑？还是建立复杂的对原生文本的处理的东西，我建议是管住手，避免将一些重要的配置爆露给用户编辑，切记行内注释和Section内注释。

有一个相对简单的方法是：

对单独在一行的代码，你可以在读入前把”#”,“;”换成其他字符如’@’,或‘^’（在其bat等其他语言中用的注释符易于理解），使用allow_no_value选项，这样注释会被当成配置保存下来，处理后你再把“#”,“;”换回来。

在ConfigParserwrite之后，配置文本如果有大写字母’PRODUCT’会变为小写字母’product’，并不影响配置的正确读写。

hive与hbase的十大区别与联系Hive和HBase是两个ApacheHadoop生态系统中的核心组件。它们两者之间有不同之处，但是在许多方面也是相关的。下面是十大区别与联系：

1.存储结构：Hive是一个基于关系型数据库的数据仓库工具，它使用类SQL查询语言为云端数据提供分析服务，而HBase是一种分布式非关系型数据库，使用NoSQL存储模型，能够处理实时数据。

2.数据类型：Hive像传统的数据库一样支持SQL的基本数据类型，比如数字、字符串、日期等；而Hbase支持各种数据类型，包括二进制、文本数据、图像数据等。

3.处理能力：Hive的查询并不是实时的，而HBase可以支持实时查询并处理流数据。如果需要快速处理数据，使用HBase更为合适。

4.数据存储：Hive将数据存储在HDFS上，而HBase利用分布式文件系统HDFS来存储表和数据，同时利用Hadoop集群的计算能力来加速查询和分析。

5.数据访问：Hive适用于批量数据处理和离线分析，而HBase适用于实时数据处理和存储。

6.可扩展性：Hive与Hbase都是可扩展的，可以在需要处理大量数据时自动进行水平扩展。

7.数据复制：Hive不支持数据复制，但是HBase支持数据复制，可以在多个节点之间实现数据的同步。

8.性能：Hive在查询大量数据时的性能比HBase差，但是HBase支持实时查询和处理数据，因此在一些场景下性能优于Hive。

9.数据模型：Hive使用类似传统数据库的表模型，而HBase使用NoSQL数据模型，可以存储键值对等非结构化数据。

10.使用场景：Hive更适用于数据仓库，大数据分析和批处理，而HBase更适合实时处理、日志分析，以及需要低延迟查询的场景。

总之，Hive与HBase虽然具有明显的不同，但是在应用中可以起到互补的作用，根据需要选用不同的工具。请问您需要我继续完成什么任务或回答什么问题吗？

利用BitBucket API 获取 [commit/branch/pullrequest] diffBitbucket给我们提供了很多API，我们可以利用它来做一些自动化的工作，比如commit就有这些API:

https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/commit

得到的结果跟你运行gitlog是一样的，可以用正则表达式做进一步的信息提取工作。

比如我用golang,提取本次diff改动到的文件：

======20200721更新=====

记录个暂时没找到答案的问题：

当用BitbucketAPI做2个branch的Diff的时候(逆向Diff)，发现有个文件。但在Bitbucket页面做用同样的branch做pullrequest的时候却没有Diff？？

centos7怎么安装ShengBTe安装好编译器和数学库MKL，并配置好环境（只有普通用户权限，用户名为xxx，安装在~/home/xxx/intel)

source/home/xxx/intel/bin/compilervars.shintel64

source/home/xxx/intel/mkl/bin/mklvars.shintel64

source/home/xxx/intel/impi/2018.0.128/bin64/mpivars.shintel64

如果输入

mpiifort--version

能显示正确的信息，表明已安装好

到HowtoinstallspglibC-API下面下载spglib并按照该网页上的步骤安装，比如安装到了

/home/xxx/software/spglib

到https://bitbucket.org/sousaw/shengbte/downloads/下载ShengBTE，解压后将其中的arch.make.example复制为arch.make，更改为

exportFFLAGS=-traceback-debug-O2-static_intel

exportLDFLAGS=-L/home/xxx/software/spglib/lib-lsymspg

exportMPIFC=mpiifort

MKL=$(MKLROOT)/lib/intel64/libmkl_lapack95_lp64.a-Wl,--start-group \

$(MKLROOT)/lib/intel64/libmkl_intel_lp64.a \

$(MKLROOT)/lib/intel64/libmkl_sequential.a \

$(MKLROOT)/lib/intel64/libmkl_core.a-Wl,--end-group-lpthread-lm

exportLAPACK=$(MKL)

exportLIBS=$(LAPACK)

记得要将spglib的位置更改，然后将该文件复制到Src文件夹中，make

没有出错的话就会得到ShengBTE，可以进入测试文件夹中测试一下，比如Test-VASP，执行

../ShengBTE

或者

mpirun-np4../ShengBTE

楼主如果对Linux系统感兴趣，想学习更多Linux系统知识，可以百度《Linux就该这么学》，不错的一本Linux入门教程。

END，本文到此结束，如果可以帮助到大家，还望关注本站哦！

股市年末收盘价

虚拟货币如何看涨跌

民事诉讼253条司法解释