像弹幕一样飘来飘去吧 >_<|||

我所接触的创业公司（三五个），打算创业或者正在创业的小伙伴（也没几个），往往心态不正，单纯为了成功（赚钱）去创业，也会做出一些不端正的事（或许不是故意）来达到目的。我觉得这么做可能会获得短期的利益，但无法长久生存下去。

也有一些公司干坏事起家（不许点名），后来用各种方法洗白白，但劣迹依然被人耻笑。

@zhimingcc https://github.com/zhimingcc 这个账户是你的？

都是小作坊的东西，怎么会正规

@luo123qiu lenth 最好前端计算，（没个百万条数据）完全不用考虑性能问题

9 12 6 的工作也干了几个月，庆幸没死，没加班费还没保险，这帮吸血鬼。

反正我没办法去荒山上架电拉网，你能我就跟着去。

ACM 算法可能会好一些，项目战斗力比较渣吧，私以为是奥数。

就近可以找老师根根外包项目（不过也没多少干货，但还是能有很多进步机会的），然后可以去找找要求不高的实习，跟一些有经验的人做做东西，应该能学到不少。

Python 能干各种事，深入学。

WPS

@luo123qiu 补充你这个问题

>遍历数据返回总数这个操作，后端执行返回和前端直接计算，哪个更有优势？

1. 如果你要知道数据库里的一张表的总数量，这个只能后端做；
2. 如果你要知道后端操作返回集合的长度，这个后端速度快，但前端处理更好：

比如你调用了一个搜索 API，想知道搜索到了多少条结果：
后端程序执行完数据库的搜索动作，就可以知道查找到的结果数量。BUT，这个数量对你很有意义么？前端不是很容易 list.length 去到么，会有很大的性能问题？
如果直接返回结果列表，JSON 结构可以是：
[
{item1},
{item2},
{item3},
{...}
]

如果给你附加一个 length 参数：
{
length: n,
results:[
{item1},
{item2},
{item3},
{...}
]
}

可以来衡量一下有多少差别。

计算一个分页数量的问题，还用纠结前端还是后端做？

来分析一下这个问题：
1. 数据总量（items）直接来自数据库；
2. 每页数据量（pageItems）可以前端指定，也可以后端指定；
3. 总页数（pages）= items / pageItems。

怎么搞？
1. 一次性将 items 全部丢给前端，前端根据 pageItems 分页展示（或者一个页面直接展示）
这个方案不可行。
2. 前端给后端提供 pageItems（如 10） 和指定页（page 如 3），后端把 21~30 项 item 返回
3. 前端给后端提供指定页（page 如 3），后端预设 pageItems（如 10） ，后端把 21~30 项 item 返回

后边两种方案都是推荐的方法。

----------
你说的问题，应该是前端需要显示[数据总量]、[当前页码]和[总页数]，这些值可以这么来：
1. 后端提供 items （也可以包含 page，这个最好前后端都维护一个。当然，后端返回的那个是前端提供的）
pages = items / pageItems
2. 后端根据前端提供的 page 和 pageItems，直接计算 pages 并返回

第一种方法更好一些。

1. 设计稿一般 320~640 给手机用就可以了，如果要响应式（看你目前也用不到），应该至少三个版式（分辨率 320/720/1200）
2. 前端自己切图比较好，自己才知道需要什么素材（话说现在的趋势是少用图片，做相应式麻烦）
3. 你的页面是 1:1 还原设计图，然后通过缩放适配不同分辨率。这种做法是错的，你要用响应式的方法写页面，然后让页面不缩放显示在浏览器中
4. Angular 适合写 App，普通的展示页就用 jQuery 好了

题主去学习一下“响应式”吧，这个对你很重要。学完了去教给你们的设计师。

For Windows http://www.getwox.com/ 吧 @qianlifeng 的作品
For Linux https://github.com/qdore/Mutate

+1

玩游戏得是 i7 15.6 1080p，看着外观顺眼的价格都不会太高。越丑的越贵

会 Linux/Mac 都算基本技能了，还要去花钱学习干啥

@is 结合 Angular 是个重要的点，不过也是最大的麻烦