最近刚学了点财务知识，所以就借机分析了一下去年三家通信公司的财务状况。 日本三大通信公司分别指的是:NTT: 9432KDDI: 9433Softbank: 9434 先看下三家的盈利能力营业额分别是13.1兆/5.8兆/5.91兆营业额YoY(去年增长率)分别是+8%/+4%/+3.8%纯利润1.83兆/6791億/5314億利润率13.92%/18.97%/17.93%三家里面，NTT规模最大，另外两家差不太多，NTT利润率虽然稍低，但三家基本都在同一个水准。 再看下他们的ROE/ROA等指标这里面Softbank的ROE最为显眼，但是他的自有资本比率最低，只有15%。 然后是三家的负债情况NTT负债最少，甚至觉得有点太少了，KDDI也算是优秀，相比之下Softbank在三家中风险是最大的。但是会看前面几年，Softbank一直都是负债很高，并不是今年突然间涨起来的，只能说用更少的自有资本去赚更多的钱，是他的一个经营特点了。 现金流去年Softbank现金流最好，三家在设备上的投资都差不多，看下股票回购的话可以发现，Softbank现金流更多的主要原因是没有做股票回购。其他两家都有不同程度的回购。 最后是分洪Softbank分红比例最高，而且近些年一直维持着高位，其他两家中规中矩。长期来看，Softbank能否维持住如此高的分红比例，会有一定的风险在里面。Softbank的分红一旦减少，势必会带动股价的下跌。而另外两家，在分红上的调整空间还很大，中长期肯定会不断增加分红金额。 综合分析三家公司，NTT虽规模最大，但是三家利润率差不太多，NTT最为稳定，其次是KDDI，Softbank的风险更大一些。但是同样的，NTT和KDDI的股息会更低一些。那么选择哪家股票，可能更需要的是对整个通信行业的预估。如果你觉得通信行业非常稳定，那么Softbank的风险可能就没有那么重要，相反它的高股息可能会更加吸引你。如果你更加注重稳定的分红，那么选择另外两家可能更好一些。 个人觉得，Softbank通信股更像是孙正义商业帝国中的一枚棋子，它是孙正义的现金奶牛，孙更偏向于从Softbank的通信事业中得到更多的现金，助力他去搞其他的投资事业。然后其他两家，更像是传统的日本企业，对于风险的把控十分严格，不太会有很激进的行为，更像是属于股东的企业。那么，如果是你的话，会选择买哪只股票呢？
在电商平台上，选择合适的产品是至关重要的，因为它直接影响到你的销售和利润。下面是我的一些选品的思路： 1.市场研究：首先要了解产品的市场和受众。规模够不够大，受众够不够多。你可以考虑使用收费的市场研究工具去查看市场信息，去深入了解关键字、竞争对手和市场趋势。你也可以通过平台提供的信息自己去总结，我个人比较习惯通过分析销售排行榜和热门商品列表去获取市场规模和销量等信息。 2.竞品分析：研究你的竞争对手，了解他们的产品、价格策略和客户评价。看看是否有机会在他们的不足之处提供更好的产品或服务。查看竞争对手的销售排名和库存水平，以判断市场潜力。 3.利润分析：计算每个潜在产品的成本，包括采购、运输、存储、平台佣金和退货率等。确保你可以获得足够的利润，以支持你的业务并扩大市场份额。 4.产品品质和供应链：选择高质量的产品，以确保客户满意度和良好的评价。只有质量过硬的产品，退货率才能低，才能做的长久。同时，要建立可靠的供应链，确保您能够按时供应产品，避免断货问题。 5.法律和合规性：确保你的产品符合所有相关的法律和规定，以避免潜在的法律问题。 6.产品差异化：考虑如何使您的产品在竞争中脱颖而出。这可以是通过改进设计、提供额外的价值或提供更优良的客户服务来实现的。 7.季节性和趋势：考虑季节性和趋势因素。某些产品在特定时间段内可能会更受欢迎，如节假日等。不过，具有季节性的产品，新手慎入。 8.长期规划：不仅要考虑当前市场状况，还要考虑长期规划。选择具有持久市场价值的产品，而不是只追求短期快速销售。 9.合理风险管理：不要把所有鸡蛋放在一个篮子里。多样化你的产品组合，以降低风险。
最近些Vue的时候碰到的一个小问题，下面这段示例代码，obj的hideField，当状态更新时，画面显示并不会更新。刚开始并不知道，后来从Vue的官方文档上也看到了解说。如果是动态追加的property，是不会自动更新状态的。 参考URL： https://jp.vuejs.org/v2/guide/reactivity.html
Selenium 最常见也是功能比较全面的爬虫工具，网上有很多使用Python+Selenium的教程，都比较言简易懂。我最初接触Selenium是用来做测试，因为有自动截图的功能，跑完每个case以后，自动截图保存一下，回头可以人工再确认，特别方便。然后Selenium还有RemoteWebDriver，可以把Selenium作为一个microservice部署到其他服务器，实现分布式。当然，Selenium最大的优点是，最接近浏览器操作，很多网站会有反爬虫的机制，Selenium可以绕过大部分（像看图填数字之类的可能还比较困难）。 Jsoup 最近碰到Selenium无法解决的一个问题就是文件下载，尤其是RemoteWebDriver的时候，下载文件特别费劲。Jsoup是一个比较简单好用的通信库，对于爬虫检查不是很严格的网站，都可以用它来获取。 HtmlUnit 个人认为介于Selenium和Jsoup之间。比Jsoup稍微更接近native的浏览器。
在系统不是特别复杂的前提下，合理的使用Spring JPA确实是挺方便的。尤其是使用repository接口，对于一些简单的sql，只需要把method名字写好，在启动程序的时候Spring就会帮你做check，测试都能省掉。但是，Spring JPA方便归方便，如果你不能准确的把握其中的细节，系统到后面数据躲起来，性能上是要大打折扣的。所以，只有准确的把握Spring JPA的编程陷阱，并且熟知他们的解决方案，才能更好的发挥Spring JPA的功效。 之前也总结过几篇JPA的编程陷阱。这次我想说一下如何N+1问题。 何为N+1问题？简单的说，就是我们想通过查询取N条数据的时候，这里面存在表间关系，理想情况下我们只需要通过JOIN就能通过1次SQL文的查询实现。但是，如果你把这个事情交给JPA去做的话，在某些情况下，需要执行N+1次SQL的查询才能取到结果。 例： 假设有这样的两个表 然后，有这么两个UserRepository。 首先UserRepository，这种情况下JPA其实是是会帮你去做inner join把user_category的信息也取出来的。但是，UserCategoryRepository的findByName的话，因为是被动的关联关系，JPA是不会inner join去取的。这种情况就会发生N+1。 除去上面这种情况，还有就是下面这样的例子： 我自己写了一段JPQL的语句，想通过自定义的查询语句去查询user表。那么，上面这种写法也肯定会发生N+1问题。 具体N+1问题怎么去解决。JPA提供了一个方案就是使用FETCH JOIN。前面那个JPARepository的接口需要自己写SQL语句。后面entityManager的例子我们实际来看一下： 写法其实很简单，但是注意这里写的是JOIN FETCH，跟native SQL的JOIN是不一样的。具体关于JPQL的写法，可以查看官方文档。 以上就是对JPA N+1问题的解读，希望以后可以更高效的使用JPA。 https://www.logicbig.com/tutorials/java-ee-tutorial/jpa/fetch-join.html
这次想说一下自定义组件的赋值问题。为了在画面中使用日期选择，导入了vue-calendar，示例代码如下： 因为需要使用的地方有多处，所以打算把它做成一个自定义组件。 然后，在view界面就可以通过下面的方式使用了： 这里说一下，component 里面，为什么要把value和dateValue分开，因为给component赋值的时候，只能通过props进行赋值。如果赋值完需要更新的话，就必须使用data或者compute进行绑定。不然的话，就会爆出下面的错误： 上面的组件的写法，可以实现父到子之间的赋值传递，但是子组件里的值改变的时候，不会跟父组件进行联动。为了实现子组件到组件的赋值联动，还需要加上下面这么一段： 子组件的值改变的时候，通过watch检测出来，然后执行 this.$emit(‘input’, val), 这段代码需要解释一下，下面两种方式作用其实是相同的。 在子组件执行 this.$emit(‘input’, val) ,其实是触发了父组件的input event。这样就可以把值传递会去了。 所以，总结一下就是，父→子之间通过props进行传值，然后子→父通过$emit进行传值。最后，完整的示例代码如下： 参考文章：https://jp.vuejs.org/v2/guide/components-custom-events.htmlhttps://vcalendar.io/datepicker.htmlhttps://recruit.cct-inc.co.jp/tecblog/vue-js/vue-emit-props/
最近碰到一个对我来说挺棘手的问题的。因为自己本来就是网络知识相对薄弱，花了好久才解决掉，所以就想着一定要好好记录下来。大概就是有两个不同的VPC，然后现在有一个新开发的Batch，需要同时访问这两个VPC内的数据库服务器。简单画了一个网络图： 目的就是为了实现instance A和B之间的通信。刚开始的时候，为了不搞的那么复杂，我把instance 改为了global access available，但是不太好用。调查了一下原因是amazon进行域名解析的时候，会把instance B的域名解析为内网地址。 当然，如果不写域名，直接写域名解析后的global ip address的话，是可以进行访问的。但是因为没有申请static global ip，所以可能会出现重启服务器以后ip变化的情况。还是必须考虑如何在两个VPC之间进行通信。查阅了一下，两个VPC之间通信的话，大概有三种方式： VPC Peering Transit Gateway VPN 这次，采用了相对简单的VPC Peering。大致的设置步骤如下： 创建VPC Peering Connection 修改Route Table这篇文章(https://qiita.com/yuppi/items/fe540e4e05920294a41c)里面讲述的很清楚 需要注意的点主要有两个：
记得三年前用Selenium写过自动测试，只不过当时用的LocalWebDriver，必须要在本地先安装浏览器(WebDriver)才可以。最近一个偶然的机会，要做一个爬虫网站的评估，所以就重新调查了一下。意外的发现原来有RemoteWebDriver这么便利的东西。通过搭建一个RemoteWebDriver，就可以替代本地的WebDriver，而且，搭建RemoteWebDriver也是异常的简单。搭建RemoteWebDriver主要有两种方法： 搭建好了RemoteWebDriver服务器以后，怎么连接进行测试了，下面有一段示例代码： 参考文章：https://qiita.com/Chanmoro/items/9a3c86bb465c1cce738a
事到如今，对于基础的git command还是掌握的不够透彻。说来也是十分惭愧。 讲一下git rebase -i 的利用场景。如果我想把自己的feature branch rebase到最新的master。然后feature branch有很多commit，然后跟master还有conflict的话，rebase的操作将会变得十分漫长。因为需要解决多次conflict的问题。 为了避免这种情况，我们可以通过rebase -i，把多次commit汇总成一个，这样，merge只需要进行一次就OK了。 使用方法如下： 首先git log –oneline确认base commit git rebase -i xxxx(commit number) 打开vim editorpick最顶端的commit，下面的commit s掉。 保存退出
