正好趁着个机会提个问题。
由于Bangumi的词条覆盖性很全面,甚至包括了一些限制性内容。我个人倒是挺喜欢Bangumi能收录这些信息这一点的,但一直以来我对推广Bangumi抱有担忧,担心随着Bangumi的发展,这个网站会被要求删掉那些内容或被屏蔽。恐怕决定那些内容的去留是这个网站发展壮大的道路上无法避开的决定,所以在这里想问一下Sai老板是怎么看这个问题的。
又:去年swift发布后,我尝试过用其实现了一个Bangumi的iOS客户端,用来追新番每章的评论。当然出于bangumi api 的不完善,以及上述担忧,我并不准备发布这个客户端。如果保持低调可以避开风险,没有移动客户端并不是无法克服的问题。
除了公司的项目以外,我前两天还刚刚作死挖了个新坑最近压力颇大……
想了想业务逻辑不是很复杂,用成熟的框架重构的话也不会花很久
你倒是去要源码看啊
我找了半天发现能用的是萌否一个程序媴(直觉?)fork的版本https://github.com/xi4oh4o/dollars-pages
其他的貌似无法建立房间,也许我的环境有问题?
css被我搞乱了,还没修
网路是自由的,又不受你国的政治审查
岛沉不可避
---- Edited
好象是我没看懂你的意思:
其实用起来感觉更多功能需要在后端上做,
Userscript 能做的功能目前都有人做了
比如 JS CSS HTML 都是纯手写,一直考虑切到 LESS 之类的。
倒是向請 sai 大大搞個沙箱條目來用,
不計入條目編輯動態的,
有時候想測試一些東西比較方便
個人的想法也是贊同前端先做,
後端架構也可以同時進行,但是不立即部署。
我在樓上說後端不夠是因為有時候後端吐的資料不是我要的,在前端上用 Script 自然難做
有读懂老代码的时间我肯定重构,反正业务逻辑也不复杂
虽说我不是技术人员
关于网站文化这方面……我觉得只有改前后提建议发声音了,像是挂城墙这样的“人际关系”类总不可通过代码阻止,但是如你所说的点赞等功能给网站带来的影响却总是可以的。
如果真有所顾虑,而sai老板的社区化开发又势在必行,那么我想建立一个用户与sai老板、与开发组之间顺畅的交流就有所必要
如果真是这样或许应该算在sai老板所说的“沟通和管理成本”上(笑)
另外我想就算是有所偏移也应该不会偏移到多远,既然sai老板是在这里招人社区化开发,那么我想bgmer总不会把自己的网站往臭了写,更何况他们愿意贡献代码
另外sai老板在#23-7、#40里提到了只是按照roadmap开发,就是说bgm城市建设规划还是按照sai老板之前的规划走
可以说还是开明专制ww
不過我是完全不贊成直接砍掉重練,不贊成換語言重寫,不贊成換 No SQL
比方说我觉得头像右侧那个气泡回复图标实在有些——不明白这形状是怎么画出来的。
这得问 Fw 为什么缩放之后变成这鬼样了……
Fw新版有个“渲染矢量到整数像素(我的理解)”功能,所以……。
Fw的一些缩放操作会挪动路径点使其总是放在整数像素位置上,我研究为什么矢量图缩小再拉大到原尺寸会变形时发现了这点。
所以在画这图标时一开始就应当在15×15(或其整倍数)的画布里画,而非画完了再缩小。你说我上次画的图标“过于锐利”就是这样画的。
什么时候才开放功能点菜...
而且bgm这个样子已经习惯了 。
用 Slack 来沟通,
虽然我并不知道国内 Slack 的访问速度如何……
不过总觉得选出来的团队成员将都是海外党
即使是麻瓜也能轻松上手使用,
总比用 Q 群好,
今年台湾 COSCUP 就用了 Slack ,
Redmine 开工单指定某人做某件事,
时间到了 bot 自己在 Slack 上 @ 当事人要做事,
当然可以羞耻 Play 直接在公开的 Channel 上 @ 当事人,
然后群众一起盯着当事人做事
Slack 即使作为聊天软件也能有更多玩法
人家要是不常上线的话在那里公开啥play都没用,毕竟有些时候码农在工作时是不会去管什么SNS的...
所以还是得看人...得找那些真心想去为这个projcet尽心尽力的...而不是那种只是为了参加project要个名声的(