人员、任务、进度、工时、周期、依赖关系 一目了然。无论项目大小、简单复杂都能轻松管理
1.现象
业务方反馈在向memcache集群写入数据时,出现不稳定。表现为向mc写入一个creative和ad对象的list,有的时候能写进去并读出来,有的时候写成功但是读不出来。
2.问题排查
2.1 复现问题
a.有的key没有问题,能够一直写+读。
b.有的key一直都是写ok,读None。
c.有的key写ok,有的时候读ok有的时候读None.
2.2 proxy的问题?
使用同一个proxy的再次复现问题,出现了之前的多种情况。所以排除proxy问
1 背景
两周前广告开屏服务突然503报警不断,先查看了各种业务监控没发现流量等有什么大变化,因为不久之前出过一次机器出问题的情况,马上去查看了机器是不是正常,果然内存几乎涨满了。大概十来分钟内存就会达到90%多,然后进程就重启了,但是从日志来看并没有什么异常情况,好在并没有将机器拖死。当时第一件事就是回滚代码,各种代码回滚到几天前,没什么效果。后来追查当时事发的一些修改改动,定位到是因为一个广告的上线导致,屏蔽该广告之后问题恢复了,但是当天还是没有查出最终问题。当时机器内
音视频同步是我们观看视频的一个基本体验,尤其对于视频画面中能看到声源动作(如:嘴型)的场景,音视频同步问题非常影响体验。
在短视频与直播APP中,采集端作为音视频的生产者,如果采集端产生的音视频源本身就无法保证同步,那么后面不管经过什么处理,都很难再让用户看到音视频同步的画面了,因此,在采集端保证音视频同步上尤其重要。
那么如何保证app在各种正常/非正常状况下尽量保证输出同步的音视频?本文就是讲述我们是如何解决上述问题的。
音视频同步的原理
音视频采集的数据分别来自
背景
不久前,我们处理了一个用户工单,该工单对应的 HQL 如下所示:
这个 HQL 看上去并不复杂,其目的不过是计算 column0 这个字段的几个近似分位点(percentile_approx),就一个 stage,应该会比较顺利地完成计算才对。不巧的是,其 MapReduce 任务在 reduce 阶段抛出如下异常:
顺着 stacktrace,我跟踪了一下 NumericHistogram(为了支持 percentile_approx,于 2010 年引
什么是XSS
跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。
XSS的攻击场景
反射型
这类攻击方式主要借助URL来实施。URL的构成分为协议、域名、端口、路径、查询几部分构成。如图所示:
近年来,前端技术日新月异,前端已经不仅仅是网页,更多的开始由狭义向广义发展。
先后涌现出了具备后端能力的node,具备移动开发能力的react native,具备游戏渲染能力的cocos2d-js,以及iOS上的热修复技术JSPatch等等新技术。
咋一看,几乎各个端都被JavaScript攻陷,大有一统江湖之势。
究竟,JavaScript如何做到上天入地无所不能?JavaScript真的能一统江湖吗?
乱世出英雄:JavaScript的诞生故事要从JavaSc
1.问题
redis slots迁移的时候,在迁移之后key数量会变少.
2.排查
2.1思考
redis 3.x也是比较成熟的产品了,为什么会丢key?别人有没有遇到同样的问题?
假设丢key了,如果key是因为expire丢失,那应该是正常,如果没有expire丢失,就是问题了,首先复现问题。
2.2复现问题
0.准备集群
造了两个节点的集群:10.1.100.100:20003和10.1.100.100:20004,最大可使用内存200M,并保证在测试
随着版本迭代,功能增加安装包体积也会慢慢增大。
今日头条576版本APK达到了25M,通过一系列的优化,到目前的607版本为12M。本文主要是介绍头条APK瘦身中用到的一些方法。
APK分析
既然是要优化APK的大小,那首先就得看下APK文件的构成。
Android Studio在2.2版本添加 APK Analyzer功能,可以直接打开apk文件,如下图所示
APK文件主要有如下几部分组成:
res主要是存放图片资源
lib主要
一.工程师对设计偏见的起源
迅速想象一副世界地图,它是什么样子的?
这样?
还是这样?
如果仔细观察上面两幅图,可以看出其中的差异:
以英文为关键词搜索,大部分世界地图的中心是美洲欧洲;但如果以中文为关键词搜索,搜索结果中地图的中心则是亚洲。
为什么是这样?
因为我们总是以自己的经验为中心建构世界,而上面的地图,不过是这种构建中心差异的展示—— 亚洲人以自己为中心,欧美人也同样以他们为中心,再往前推到地心说,则认为地球是宇宙的中心。
真实的世界非常复杂
对于一个带有视频播放功能的app产品来说,视频全屏是一个基本且重要的需求。虽然这个需求看起来很简单,但是在实现上,我们前后迭代了三套技术方案。这篇文章将介绍这三种实现方案中的利弊和坑点,以及实现过程中积累的经验。
需求要点:
在屏幕旋转的动画中,需要保持播放器之外的界面布局(比如“First View”等几行字的布局不应该发生变化)
全屏切换到小屏,小屏需要回到原先位置
对于这三种实现方案,我写了个demo分别示意。三个方案分别在demo的三个tab中。
原始