年前往往优惠力度这个东西是不透明的，有可能更贵了。呵呵。
建议年后再买，年后都是真折扣。

你们工程还没有开始，连报价单都没有给你，哪里来的“材料已经购买”，买了什么材料？
下次建议现场争论时，小心仔细的录音。

哎。
不过我建议你，以退为进。坐下来，跟对方领导好好谈，如果他态度也可以，你们好好商量好怎么办，如果问题能得以解决，就还好。

1 个是你身边没有法律方面的帮你，你会很吃亏，人家是老油条。

没什么经验。
之前也遇到过类似的问题，就是选了一家小装修公司，签订合同后拿回来 3 份文件。

后来装修期间发现问题越来越多，就认真审阅了下各方面的材料。

3 份材料的总金额不一致：
《家庭居室装饰装修工程施工合同》 82891
《 XXX 装饰工程集团 368 包干价项目内容及报价》 78891
《特殊优惠申请表》 78891

接下来看合同上的三期工程费用：
一期： 55% 45540 元
二期： 40% 31556.4 元
三期： 5% 4000 元。

而实际上，一期如果是按跟我们约定好的 78891 元，则应该是 43390.05 元，二期 31556.4 元，三期 3944.5 元。
结果它连按合同总价 82891 元都算错了，一期以 82891 元的话， 55%应该是 45590.05 元，二期应该是 33156.4 元，三期应该是 3315.64 元。

一连串的问题，我反复啃 3 份文件，找里面的漏洞。
最后让家里的长辈去闹了下，二期只付了 28747 元，尾款只付了 1000 多远，比 78891 元还少了点。嘿嘿。

其实你后面还会遇到更多问题。
一开始一定要选大的、知名的、有真正设计师的装修公司…… TAT

不过我已经圆满结束了工程，因为施工团队很给力，装修公司的混蛋销售很不负责就是了。

我的建议是你让长辈去闹- - 年轻人搞不定这种事。

我也是这么看待小程序的。
媒体就是炒作，过分放大了优点，再反过来攻击这个优点，造成声势浩大。
其实就是看点不同而已。

问女朋友，不要自己乱买。

按照规定的来，摸着 F 和 J 的图起点来定位。

- - 毕竟学过...

已经被微信打败。

一般来说，双方都要做的。
如果前台做了后台没做，那后台可以滚了。
如果后台做了，前台没做，那一般情况要看有没有交互，如果有交互就一定要做。

GIT 简单到 1 小时就够了...
WINDOWS 用 GIT 有点麻烦，你必须先安装好一个叫 GIT GUI 的东东（貌似是叫 GIT BASE ）。
有了这个，你才可以使用各种 GIt 工具，比如 sourcetree 、小乌龟等。
其实不用工具也可以，直接命令行啦

别人花钱买了然后喷的……怎么说也算贡献过啦。

TP5.0 不是开源的了？

这种是年前发还是年后发呢？

oschina 每个月挂几次吧，以前常用，用了 1 年，最后一个问题是导致库都必须换，就是没有 history 了咯。
忍无可忍，换了 coding ，现在没有什么问题了。
基本是半年才会遇到一个大问题，但是整体影响不大。
服务更加稳定。

而且 oschina 的问题，很难反馈到。

coding 的问题，在冒泡里一发，技术和管理人员就跳出来了。。。

典型用户就是具备一定被掌握象征的用户群体。
还有一种说法是终端用户，泛指产品针对的用户群体。而其中，有一部分掌握最深入的，叫典型用户群体。
平均用户没这个说法，至少得有上下文。

@banks0913 你可以用 ViewModel （ MYSQL 的 View 视图）弄串表。也可以用 ORM 的特性，实现 hasmany 或者 belongs 这种。我推荐 ORM 。

两种方法都有其各自可取之处，取决于实际业务中，是否有变动来抉择。

第一种是建立在你肯定这个东西不再多变的基础上。它的好处是节省了查询效率、表空间等。
第二种适合多变的需求。它的好处是改来改去对其依赖的功能没有影响。

如果你的老板经常发春，改来改去的，今天附件是 1 个，明天附近是 2 个，后天附件多了个 ext 、 fakename 、 outside_link 之类一堆扩展字段——这种可能性及高，那肯定是用第二种。