[Android] 判断ListView是否滑到顶部

该场景很多,下面是终极方法,特别对于API小于14的设备,可能要考虑顶部有padding的情况:

private boolean listIsAtTop()   {   
    if(listView.getChildCount() == 0) return true;
    return listView.getChildAt(0).getTop() == 0;
}

该处有详细讨论:

http://stackoverflow.com/questions/7318373/how-to-find-out-if-listview-has-scrolled-to-top-most-position

 

[Android] ListView有Header时的position情况

经常需要在ListView前面加个Header View,这时获取ListView的position会有问题。

1.首先确保addHeaderView方法必须得在setAdapter之前被调用。

2.在OnItemClickListener的

public void onItemClick(AdapterView<?> parent, View view, int position,long id)

方法中,position是从header开始计算的,包括了header。那么要获得除去header后的正确位置应该怎么做呢?

方法1,position减去 listView.getHeaderViewsCount().

例如想得到ListView中可视的第一条item的在数据中的索引,就用getFirstVisiblePosition()减去getHeaderViewsCount();

方法2,在onItemClick不要直接使用我们声明的adapter,而是用ListView里的那个decorated adapter。

获取它的方法就是调用parent.getAdapter()

参见:http://blog.csdn.net/faithmy509/article/details/11521903

3. 如果 listview 调用了一次 addHeaderView,则

listView.getFirstVisiblePosition();

listView.getLastVisiblePosition();

listView.getChildAt(pos);

会以 headerView 为第0个view,item 的 pos会从1开始。

JNI崩溃问题定位

一般native代码导致的崩溃问题,奔溃日志提示大概类似这样:

Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 13261

只有这样而没有详细的调用栈信息,这样我们开发者无法定位到JNI中到底哪一行导致程序崩掉的。根本无法定位问题所在,就更不用说解决问题了。

好在NDK给开发者们提供了ndk-stack工具(在NDK根目录下),我们可以通过ndk-stack工具来查看so库中崩溃的堆栈信息。

NDK编译时已DEBUG模式编译

如果是使用命令行编译,则使用如下语句:

ndk-build clean all NDK_DEBUG=1

clean all 的意思是编译之前先清理全部上次编译生成的内容。NDK_DEBUG=1 意思是生成调试版本的文件。加了这个参数后 调试的时候能定位到源码行数。

如果是使用gradle,则写法如下(注意这里已经覆盖了gradle默认的NDK编译,详细请前往《Android Studio覆盖了gradle默认的NDK编译》):

task ndkBuild(type: Exec) {
    commandLine 'ndk-build', '-C', file('src/main/jni').absolutePath, 'clean','all', 'NDK_DEBUG=1'
}
tasks.withType(JavaCompile) {
    compileTask -> compileTask.dependsOn ndkBuild
}

最后记得在AndroidManifest.xml设置debuggable为true ,在Application节点中。

ndk编译so库并运行程序

前提是要搭建好NDK开发环境并在项目中集成NDK,不会的可以参考Ubuntu下NDK编译环境搭建及在Android Studio中集成NDK

为了演示,我这里先模拟一个错误:

JNIEXPORT jstring JNICALL Java_com_liuling_ndkjnidemo_JniUtils_getStringFromC
        (JNIEnv *env, jclass obj) {
    int * p = NULL;
    *p = 1;    //这里会导致程序崩溃
    return (jstring)(*env)-> NewStringUTF(env, "I am string from jni");

}

使用ndk-stack工具定位崩溃信息

在命令行中执行如下命令:

adb logcat | 你的NDK所在的路径/ndk-stack -sym 你的项目所在的路径/app/src/main/obj/local/armeabi

这里要确定,ndk编译后生成了”你的项目所在的路径/app/src/main/obj/local/armeabi”目录,也就是这个目录要存在。

执行完这个命令之后,终端会阻塞在那,一旦程序崩溃,就会在终端打印出崩溃信息栈。如图所示:

从崩溃信息可以看出导致崩溃的代码是在com_liuling_ndkjnidemo_JniUtils.c中的13行。

打开com_liuling_ndkjnidemo_JniUtils.c文件查看代码,确实是在13行出的问题。

能够定位崩溃所在的位置,就对于我们排查问题来说有很大的帮助,其实修复bug大部分时间都是在找哪里出的问题,能够快速找出哪里出的问题,问题也就很快修复了。

转自:http://liuling123.com/2016/06/ndk-stack.html?utm_source=tuicool&utm_medium=referral

程序员如何花式赚外快?

转自:http://www.58maisui.com/2016/06/14/a-188/

印象中程序员好像都找不到女朋友(其实是扯淡),但是程序员花钱可是分分钟的事情。服务器、域名、苹果电脑,以及appstore里一堆的收费软件、还有那么多高科技的VR设备,所以很多开发宝宝都是入不敷出的节奏。

当然作为一名合格的程序员你必须学会以下几种花式挣外快的方法,这里很多开发宝宝要说了,不就是接私活接外包么?瞧,肤浅了不是,比起接私活,还有很多方法好不好?

一,外包私活(最笨的方法,来钱快呀)

最好还是能够接到海外的单子,比如freelance.com一类的网站。主要是挣美金的感觉还是太爽了,另一方面付出和回报总算比较合理了,之前看到像做一些比较简单的ios 模块化项目,这种很多开发者一两个周末就能做完的项目,也可以到400~600美刀,最重要的一点,在国外接单子不会被老板发现。

国内 www.proginn.com申请签约后派的单子价格还说的过去,但是很多同学都发现国内的圈子实在太小了,曾经碰到一位开发者很无奈的跟我说,之前的一面的HR,二面的BOSS,还有隔壁的同事都在上面有信息,他很担心透漏实名和真实的公司部门信息,这么高调,万一火了被老板发现肿么办?

而有的同学则理直气壮的说,只要我本职工作做的出色,你管我怎么接私活呢?当然大部分公司的劳动合同里面不可能写禁止兼职。但是长此意外如果碰到小心眼的HR,HR发飙了会不会偷偷给自己小鞋穿呢?如果碰到和PM意见不合,只要你说需求很难短时间内做完,而自己又偷偷的接私活的话,你猜老板会不会生气?

当然,类似猪八戒这种的威客站还有很多我就不说了,感觉不适合大家。

二,Side Project

相比较于接私活,做一个比较棒Side Project还是非常靠谱的。

Side Project可以形成一个长时间的财务输入节点,不但可以提升自己而且可以利用自己的知识点来完善和充实自己。

推荐两种做法:

1,比较实用的垂直领域应用,这类软件往往在应用市场很受欢迎,当积累多了以后你就会发现还是有很多用户愿意付费的。

2,开发一个功能强大的基础应用,类似wordpress,可以方便用户直接在上面添加代码订制成熟与自己的应用软件。

很多开发宝宝会说,我写的Side Project很难卖出去啊,这里教大家一个非常简单粗暴的方法,看看现在卖得非常好、但是功能和技术却不是非常达标的项目,前提自己能做的比他更加完善,然后做一个和他差不多的产品,只卖它一半的钱。

三,做咨询

如果你在圈内口碑不错,或者在某一个技能方面非常厉害,做咨询挣钱是最舒服的,想想在咖啡厅给别人一些意见,或者把自己的经验传授给别人就能换钱是一件多么开心的事情。前提,你的语文不能是体育老师教的!

目前国内三个这方面做的比较好的网站:

在行(http://www.zaih.com):果壳网旗下的大而全的咨询网站,算是做得比较早,但是上边技术类专家好像不是很多。

缘创派(http://q.ycpai.com/h5/lightPartner/expertList): 缘创派的轻合伙栏目,服务的是互联网创业者,适合喜欢创业的技术大牛。

极牛(http://geekniu.com) : 程序员版本的在行,简单的看了下,虽然目前好像还没有推广开,但极牛的专业性较强,比较适合开发者入驻。

现在做咨询也要实名了,相比较于接私活,做咨询时间短、效率高、人很舒服,也不会影响到本身的正常工作,大部分公司鼓励技术交流,属于比较高大上的路子。

当然除了网站建设、APP开发外,收费QQ群也是可以做的。现在创业交流看似很火爆,但真当你遇到难题后真正能快速帮你解决问题的人是真少。如果搞一个技术创业支持QQ群,找一些创过业的同学、正在创业的同学、做投资的同学、做法务的同学,面向想创业的同学开放,每人收个几百块的年费。给创业者提供廉价的技术咨询类服务还是非常受大家欢迎的。

四,文章投稿

很多开发同学都有自己的技术博客,其实有营养的文章投给一些网站是可以赚取稿费的,只是很多人不知道。

例:InfoQ,这家网站喜欢收三千到四千字的深度技术文章;稿费是千字一百五。虽然钱不是很多,但是一篇好的文章就可以晚上吃顿大餐了。InfoQ比较人性化的地方是版权要求没有那么严格。文章首发后,还可以发布到自己的博客;以后自己引用只需要标明来源infoQ即可。

关于infoq的详细说明:http://www.infoq.com/cn/article-guidelines

其实现在出电子书的收益是最划算的,传统渠道发行的书挣不到什么钱,通过网络销售的就更低了。

五,教学视频

在线教育火了以后,录制教学视频赚钱也是一种不错的选择。推荐(designcode.io)这种自主发行的模式,因为挣的钱比较多。

有的同学又要问了,现在那么多免费视频,为什么还要买你的收费视频?

因为绝大部分教学视频,往往都是真的初级别的教学,和现实开发中遇到的问题天壤之别。很多简单的案例都是教学设计,有一定的参考性,但是缺乏实战意义。

分享一下个人的操作方法:

当我开始做一个开源项目的时候,会完整的把整个开发过程录制出来。推荐一款好用的录制工具:开源的屏幕录制工具OBS,等我的开源项目做完,就把它放到GitHub上面,免费给大家用。等版本迭代稳定后,再从录制的全量视频中剪辑出一系列的教程,整理出一系列的文章,放到网站上做收费课程。

首先保证所有遇到的问题都是真实的,不是想象出来的,学习过这个课程的人,可以独立的将整个项目完整的实现。

而且没有特意的录制过程,所以教程其实是软件开发的副产品,投入产出比更高。

如果你的项目的确写得好,那么用过你软件的人可以成为你教程的客户或者推荐员;如果你的教程写得好,那么看完你的教程的人会成为你软件的客户或者推荐员。

六:内推

加入你在BAT等等比较知名的互联网公司工作,如果你的朋友圈都是开发者,那么经常会遇到跳槽的开发者,这个时候千万别错过你挣推荐费的大好时机。

一般来讲,公司内推的钱会少一些,我见过的3000~6000的居多。一个朋友是阿里的P6,内推成功一名P7直接赚了6K多,大公司都会鼓励大家内推,老板也乐意看到这样的事情。据说暴雪没有HR这个部门,员工都是内推的。

适合程序员的画图技法

之前写一些技术文章时,经常有读者留言问我是用什么工具画图的。其实我感觉他们很可能问错了问题,因为我曾经为了画好图尝试过各种不同的画图工具软件,但最后发现能不能画好图和工具的关系并不大。

为何?

程序员不是写代码的么,为什么需要画图?很多程序员会认为写好代码就好,画好图有什么用?程序员成为架构师后是不是就天天画架构图,成为了所谓的 PPT 架构师?如上这些疑问,好几年前也曾让我困惑过。

在一篇文章《在首席架构师眼里,架构的本质是…》提到了一个架构师能力模型(下图),结合我自己的经历和经验,这个能力模型针对架构师这个岗位来说还是比较符合的。

一个程序员做了很多项目,写了多年代码逐步成长为一名出色的程序员。从上面的能力图中可以看出,一个出色的程序员离一个架构师还差好多其他方面的能力。我们以前以为程序员积累了足够经验就会自然成长为一名架构师,但其实架构师并不是程序员自然成长的一个延续,只是因为架构师的工作相对管理岗而言离程序员和技术更近,所以我们对它产生了这样的错觉。不断在「出色的程序员」这块领地内不断的耕耘和出色下去会让你成为该垂直领域内的技术专家,这才是程序员自然成长的延续。

因而,程序员出色到了一定程度后想成长为一名架构师,就需要看看能力模型中的其他方面。而掌握好画图技法,我觉着至少对其中的抽象思维、沟通交流、平衡取舍与透过问题看本质都有帮助。至于多领域知识和技术前瞻性这两方面好像确实和画图的关联性不强,但如果多领域知识不限于程序技术领域,画图也算一个领域的知识吧。

今天这个时代的地图软件我们都用过,一个国家、一个城市、一个街区,地图软件总是在不同的抽象维度上来展示地图。而对于一个复杂的软件系统,也需要类似的不同抽象维度,系统的全貌,不同子系统间的关联和交互,子系统内部模块间的接口和调用,某个关键实现点的处理流程。一个架构师应该可以在这些不同的抽象维度上把系统或系统的一部分清晰地描绘出来。

当在不同抽象维度上描绘了系统的各个重要方面,我们才可以更好的发现和找到系统的症结。如果解决系统的问题就像走迷宫,你是直接钻进去反复尝试寻找出路,还是站在更高的维度俯视迷宫再找到最佳的问题解决路径。这就是透过问题看本质领域一个方面的体现。

关于沟通交流,俗话说,有图有真相,哦,不对,是一图胜千言。有些程序员写技术文档啪啦啪啦的写一大堆,有时真不如一张清晰的架构图或交互图让人更快速清晰的理解到。在对系统有了抽象全面的多维度呈现,清晰准确的交流,直击了问题本质,那么正确而适当的平衡取舍也没那么难了,对吧。

如何?

上一节探讨了画好图会带来什么样的收益,这一节我们看下如何画好图?画一个清晰易懂的技术架构或交互流程的说明图例需要什么专门的绘图知识与技巧么?另外为了画好图会花费大量的时间么?

在过去几年关于如何画好图这个课题上我做了好些摸索和实践,想取得效率(画图花费的时间不会多于比用文字来描述同样的内容更多)和效果(图例表达的效果应该比文字描述更好)的平衡,在这个过程中收获了下面一些基本认知和自我感觉还不错的实践方式。

图形

我画技术图例时只会使用一些最基础的图形,比如:矩形、圆、三角、菱形、气泡、箭头,这些最基本的图形几乎所有的画图软件都会自带的,所以工具的依赖性很低,但选择的效率很高。当然如果有时为了表达和一些著名外部系统间的交互,这些著名外部系统可能都有各自著名的 Logo 图标,也会直接使用它们的 Logo 图标。

像下面图示,就是我常用的一些画图图形元素。

颜色

有时系统的组成比较复杂,只用基本图形不足以表达所有不同的系统组成部件,这时就需要用颜色来区分了。那么下一个问题就来了,该用哪些颜色呢?我的答案是使用大部分人觉得美的颜色。那大部分人喜欢什么颜色呢?当然我没有作过任何调查,全凭脑袋拍的。我觉得大部分会觉得彩虹是美的,所以我一般用得颜色就是彩虹七色外加两种经典色:黑、白。这样就有九种颜色加上几种基本图形,可以组合出几十种表达不同组件的图形元素,基本够用了。

彩虹七色包括:红、橙、黄、绿、青、蓝、紫。但七种颜色的选择也是有优先级,在一本讲设计的书中 Designing with the Mind in Mind (中文译名《认知与设计》,其实我觉得译名没有原名那么的有感觉)提出了下面一些色彩使用准则:

  • 使用饱和度、亮度以及色相区分颜色,确保颜色的高反差,因为人的视觉是为边缘反差而优化的。
  • 使用独特的颜色,因为人最容易区分的颜色包括:红、绿、黄、蓝、白和黑。
  • 避免使用色盲无法区分的颜色对,比如:深红-黑,深红-深绿,蓝色-紫色,浅绿-白色。
  • 使用颜色之外的其他提示,对有颜色视觉障碍的人友好,而且也增强了可理解性。
  • 避免强烈的对抗色,比如:红黑,黄黑

所以你看为什么交通灯是:红、黄、绿。为什么乔布斯选择这三个颜色作为 Mac OS X 操作系统中所有应用窗体的按纽颜色,这也是暗合人类的视觉认知原则的。所以我现在多选择是白底、黑字、黑色线条、色块优先选择:红、绿、黄、蓝,实在不够用了才会选择:橙、青、紫。

当然红有好多种红,绿有好多种绿,我用哪种?看下图所示,给出了 RGB 三原色的配色数值(别相信自己的眼睛,不同显示器上看到的效果会有差异,作为程序员需要精确点)。至于为什么是这个选择,后面再说。

审美

除了基本的图形和颜色选择之外,另外一个关注点是审美。审美对最终的效果呈现有很大影响,这得感谢苹果总设计师 Jonathan Ive 把大众的审美倾向全部带入到扁平化时代,所以实际我只需要把图形弄得扁平,去掉立体、阴影什么的,看起来就还不错了。

几何?

探讨了如何,我们接着看看几何。此「几何」不是数学里的几何,而是曾几何时,我们想象中很麻烦的事原来如此简单。掌握画图技法到底代价几何?又价值几何呢?

三年前,我画的技术图示(来自以前一个分享 PPT)大概是下面这样的,总是觉得不好,不太满意,却又不知道不好在哪里,该怎么改进。然后就归罪于工具不好用,从一开始用 Viso 画,后来尝试了 Mac 下的专业绘图工具 OmniGraffle,觉得太复杂后又找到个在线绘图网站 draw.io,感觉还可以,但由于是国外网站,访问效率不太好没多久就放弃了。之后需要做一些 Slide 演示时,用了 Mac 下的 Keynote(相当于 Win 下的 PPT),需要画技术图示时想如果直接在 Keynote 里画最省事了,然后就开始用 Keynote 画了。

前面写到颜色选择时,提到为什么就选这种红而不是其他红,其实这就是 Keynote 在白色背景下默认提供的调色板色块选择。作为程序员提供一个软件的默认参数,通常的道理是这个参数可能在大部分场景下都是最优的。所以我倾向于认为 Keynote 的默认色块是这个背景下的一些最优纯色选择,而且我自己肉眼看起来也还感觉不错,这样就省了打开更高级的配色参数界面,绘图的效率又更高了,代价也更小了。所以按这个指导原则,重新画下上面这个技术图示大概就像下面这样,花费的时间绝对不会比画上面那个更多,但呈现效果自我感觉确实要好多了。

所以,学会使用一种简单的软件,使用简单的图形和配色,在最有效率的情况下画出一幅效果还不错的图例,也是很有价值的。当然很多程序员会认为只有写出的代码才有价值,其实这里可能忽视了一个大部分程序员都认同的观点:代码也是写给人看的。程序员不会认为一份机器能运行而人很难看懂的代码是好代码,而画好图能更好的帮助你去思考代码的组织和呈现方式。

本文只是介绍了一种极简的绘制技术图例的技法,毕竟我们画图只是为了追求讲清楚一个技术或展示一个系统,不需要考虑任何多余的艺术性。最低的代价,还不错的效果,在效率和效果之间取得性价比最高的平衡。

程序员的工作性质和习惯更关注实现而忽略呈现,有时酒香也怕巷子深啊,何况还未必是茅台酒。

转自:http://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=2650610560&idx=1&sn=f01ef209d63f0ea1fbccbba0b6e351d0#rd

某牛人总结的fackbook面试经历

原文:http://cenalulu.github.io/mysql/how-i-become-a-facebook-dba/

如果你将要或准备参加FB电面/面试的话,下面是一些我个人感觉比较需要注意的点

  • 没有做过的或者不清楚的知识千万不要写在简历中,任何信息都有可能在电面中被考察到
  • 申请时留的邮箱,保持畅通可用,建议每天查收新邮件。
  • 电面环境建议安静,温度合适,电话信号良好。
  • 电面准备一条有麦克的耳机(普通手机的通话耳机就行)。
  • 注意保证手机电量充足
  • 王淮的《打造Facebook》一定要看,我的大部分面试流程的疑问都在书里得到了解答(PS:我真的不是出版社的托!觉得我是托的可以看PDF。PPS:出版社别打我)
  • coding电面之前,建议先通过stypi练习一些简单的算法题
  • 关于白板题目去哪里找:Leetcode TopCoder, Codeforces, Project Euler 都是不错的选择
  • 关于薪资范围, 可以参考Glassdoor上给出的标准基本上很准
  • 关于家庭
    • 收入:以Facebook的待遇,一个人养活一家三口基本不是问题,会有少许结余。
    • 签证:Facebook的指定代理会帮一家三口搞定一切(但是不包括申请人的家长)