Monthly Archives: November 2013
- State of the Future Keynote with Lew Cirne @New Relic FutureStack13
- Developers: 30 minutes discovering how New Relic monitors your servers
Just wandering around YouTube and arrived at the above videos. I often hear the New Relic name at the podcasts I regularly listen, and also I’ve tried the New Relic’s Add-on at Heroku for a while. But, I haven’t been able to deeply dig into the features before.
The above ones mostly talks about its summary, but I could grasp the key features of them with nice demonstrations. The last part of the keynote one was about the new Rubicon project, which provides simple query methods to analyze the pre-gathered data. It sounds pretty much nice, compared with the custom scripting on raw data.
The demonstration from the CEO himself was nicely organized to present the power of graphical interface of data visualization. It’s nice to see the technology company’s CEO with fluent skill of demonstration backed with deep understanding of their technologies.
Nice presentation about how GitHub is managing the team structures as it grows.
The official “about” page is indicating that there’re 223 HUBBERNAUTS (employees?) at the moment. GitHub seems growing nicely, and it’s great to host millions of users and repositories with this number, including the GitHub enterprise.
The “60% remote” team structure is interesting. The following points indicated are nice.
- GitHub used to have all-member meeting at the San Francisco two times a year. Now it’s reduced to one, and having more team meetup.
- GitHub has 150 chat rooms opened. Having separate rooms is good for S/N rate. Not going so crazy along with push notification when your name is mentioned.
The daily-based communication tool and constant meet-ups would be the crutial factors.
Personally, I would like to work remotely, but I can think of myriad issues that may occur in my environment. Many of the issue could be technically resolved (as indicated in Remote – Office Not Required book), but it’s difficult to go over the threshold at the static and large organizations, maybe. I sometimes envy the remote environment.
Lastly, “if there’s disagreement, both sides are wrong at some level” statement at the Q&A part was interesting too. If the discussion is abstract and imaginary, it tends to cause disagreements. Having concrete points or codes are the good standpoints of the discussion.
A nice post about functional programming and promises. Promises are interesting concept, and it would be a powerful tool to assist the concurrent programming.
However, I still feel the Node’s callback-based model is a reasonable approach to lower the thresholds of event-based concurrent programming. Having the compact first-class functions, the most of the expressions are concise, compared with heavy-weight languages like Java.
I’m now learning the Futures and Promises on Scala, but I’m having difficulties on grasping its programming style. It requires abstracted ways of thinking, and I’m struggling. Need more study.
Just watched the 2 keynotes of AWS re:Invent last week, which are 3.5 hours total.
The number of feature announcements at this conference would represent the fast-growthness of the AWS. It’s interestingly expanding the range of services on every aspect of cloud-based solutions. During the keynotes, some users are presenting how they’re using AWS infrastructure. It may be somewhat biased, but definitely it was difficult to achieve the recent-growth rate of many web services without cloud-service providers, lead by AWS.
Also, Amazon Workspaces would be an another direction of expansion on top of similar underlying technologies. Having a strong infrastructure on software/hardware, physical/service aspects, Amazon seems heading for dominating the world.
Aside from the main topic, one thing I got remembered is the “Working Backwards” concept in Amazon, which was mentioned in the 2nd day keynote. I didn’t know, but it was mentioned in the CTO’s 2006 blog-post.
It’s an interesting approach to nail down the feature set which users are expecting. Maybe similar process are being performed at the product planning phase in many organizations, but “Press Release” and “FAQ” part sounds interesting. It should represent the key advantage of the product/feature with simple and persuasive reasoning.
Just uploaded a property-based testing library for Elixir (QuickCheck style). It’s trial implementation, but basic features are now working with ExUnit.
I was taking a scala course at coursera, and one exercise was to use scalacheck, which is the scala version of QuickCheck. QuickCheck is an automatic specification-based testing library. The original one is developped on Haskell, and it’s ported to many languages. There’re several Erlang’s libraries too, but I couldn’t easily use it on elixir, since the predicates are based on macros. Then, I tried to create a wrapper for one of the library (krestenkrab/triq – GitHub).
I didn’t know about the QuickCheck before, but it’s pretty much interesting concept. The declarative testings work as more clear specification, and also it helps on creating test-data. Thinking about test-data with boundary or abnormal conditions are sometimes cumbersome, but QuickCheck with various generators helps it nicely.
It’s a nice talk about functional way of thinking. The “functional” provides a different way of programming style from the object-oriented and imperative ones. The concept is not about specific language or syntax, but rather a different paradigm to think on problem solving.
The Functional Java is one example to apply this paradigm in the Java through libraries.
The library provides functional data-operations like map, filter, etc., and it can be applied into the familiar object-oriented and imperative Java syntax.
Also, Java is now equipped with lambda expression and streams. Along with Scala, the functional style seems getting into the mainstream gradually.
I was yet a little skeptical about the paradigm of functional programming, mostly because it is difficult. It requires more abstracted way or mathematical thinking, rather than more concrete and basic imperative way of thinking. However, recent adoption of functional paradigm in the popular languages would be a good indicator that certain paradigm shift in the majority area is now happening.
- Wicked Good Ruby 2013 – Understanding Ruby’s Method Cache
- Speakerdeck – Understanding Ruby’s Method Cache
Just watched the above explanatory video on ruby’s method caching. Maybe it’s a little old topic which is mostly about ruby 1.9 change, but it was a nice resource for me (which means I didn’t know much about this topic).
It talks about the ruby’s dynamic method resolution, and how MRI is implementing the caching of method dispatch, like the following.
- Ruby allows defining methods dynamically and it’s required to check the class and module hierarchy every time methods are called. To alleviate the cost, method caching is introduced in ruby 1.9, but yet there is performance penalty in defining methods due to cache busting.
- The method cache is maintained globally with a generation counter, and once generation is incremented, all the cache becomes invalidated, and need to pay the price again. Even a innocent-like OpenStruct.new internally defines singleton method, and causes the expiration of global cache.
I didn’t know the caching is maintained globally, and the blog post (MRI’s Method Caches) is talking about improving by limiting the scope. Also, I can see the JRuby’s doc (JRuby Internal Design) talks about caching too, and I need more research on this one.
This kind of dynamic feature and mutable nature of the language is a major advantage of ruby, but the performance penalty also comes with it. With this in mind, the immutability in core framework sounds more like an interesting approach, as Scala or Elixir(Erlang) is advocating.
Just completed the “remote” book from 37 signals. The above site has nice introductory video for 37 signals case.
I sometimes ponder about working apart from the office – from home, coffee shop or any other place. However, in the actual life, everyone is packed in the office from the morning to the night, with the “physical” meeting filled in the everyone’s scheduler. There’re difficulties getting out of this condition for myself. But, I found this book insightful about working remotely discussed on several different perspectives.
The followings are some of my reading notes.
As discussed in the book, it’s a major issue for completing tasks which requires focuses. Many of the skilled members get interruptions from the colleagues asking for helps constantly, or from scheduled meetings. Then, some of them are forced to come very early in the morning, or work over the weekend. It’s a tough situation.
However, working remotely has different types of distractions or temptations. Some workers may lose focus, though motivated/passionate workers might go different direction (overwork). Freedom is not always a happy path, and it requires certain commitment or regimen to make it work. Some ways to avoid distractions are discussed in the book, but still it would be a large fear. With this in mind, I like the concept of more loosely implemented way, like work from home in the morning and come office afternoon.
We sometimes work with contractors in foreign countries, and the major communication path is e-mail and messaging. It sometimes cause issues, due to the misunderstanding on expected outputs. It may not only be about “communication”, but F2F chatting has been working as a safe-net for avoiding the this type of issues. It can/should be replaced with phone calls, WebEX or video calls, but it it would require certain cares from members or leaders for maintaining the constant communications. As indicated in the book, setting up the online infrastructure or having constant F2F meet-up would be a good approach.
One interesting point is there are myriad reasons why people have to—or want to—move, and they don’t necessarily have to leave the company if they’re working remotely. Maybe that’s the one good reason that 37 signals can hire or maintain the talented people from many locations. Most of the time, employees are tied to one office location, and forced to leave the company due to certain reasons. It’s unfortunate.