OJ

Agreed. The cross pollination required to get security into organisations correctly isn't there. Orgs see security as a pain in the ass, and not an investment/insurance policy.

I feel your pain in those latter points.

The notion of a national certification plan is being laughed at by anyone who is in the industry for the right reasons. Those involved in the classic commoditised scan-and-bang assessments will love it as it'll continue to keep the cash flow churning.

Some have even suggestion "cyber conscription" to force people to do government work if they're capable. This, and the recent articles indicating that the government wants people to "volunteer" their time goes to show that they want people for the lowest possible price.

The problem in Australia here is no different to overseas: the focus is on useless certifications and compliance, cheap resources, and security theatre. CEH and CISSP are alive and kicking because of this.

All of the above is beside the point. Troy made CEH PluralSight content because PluralSight's people wanted it. It's really that simple. The blog post is just marketing for that content.

While the tech scene in Australia may be behind the times in a few ways (possibly security as well), Troy's view here is in no way affected by living here. This material was created because PluralSight wanted CEH-related material, as their viewers (world-wide) were asking for it. Full stop.

Blog posts like that are designed to steer traffic towards course views and "time watching the content", without which PluralSight authors don't get paid.

Thanks rcconf. Yeah I did feel like a bit of a muppet for missing it. I'm going to say "It was late and I was tired" and try to hide behind that as an excuse ;) I'm pretty sure I would have found it eventually, but I was time-poor and thought it'd be a good idea to call in the cavalry. Stephen was great, plus he knows the RDI code inside out for obvious reasons. I still feel like I contributed though!

This seems like a rather unjustified and wanton punishment to me. I can't see anything in his history that is worthy of such treatment. I scan around other areas of HN and see people who are blatant trolls appearing everywhere and they aren't hallbanned. Yet someone, like josephcooney, who appears to have a brain and attempts to be actively involved in moderate and reasonable discussion is axed?

Just goes to show that HN is becoming a ghetto, that's if it isn't already one.

Poor form if you ask me.

You said that you don't like the availability issues then state "but at the moment MongoDB is about as good as it gets."?

Just. Wow.

Get your head out of the sand mate. MongoDB is nowhere NEAR as good as it gets.

That is definitely part of it. When I first started writing I needed to remind myself of this quite a lot. Thankfully I haven't really needed to do that for quite a while now. I enjoy writing and I do it when I can. The goal continues to be learning with the added bonus of helping others along the way. It hasn't ever been, nor will be, about traffic.

Cheers for the comment.

I agree with your points. It is hard to make something this small have meaning across the board. This is part of the reason why I targeted the thought at tech blogging in particular. This net may also be too wide, but in my opinion the point holds when it comes to that type of writing.

At no point did I say "hide your writing". I think it's clear that the sentiment of the post was not to hide the stuff that you write, but instead to write for the right reasons. If you write for the purpose of pleasing others you'll struggle. If you write to please yourself you'll be surprised just how many others you please in the process.

Thanks for the comment. You're correct, I didn't write this for myself. I decided to post it after a conversation with a few people on Twitter earlier today. I wanted to post something short which summed up how I felt about things.

While this wasn't written for me it is the summation of how I approach the way I write. My goal is for me to learn or to share the things that I think I've learned. This approach has worked well for me. While writing I learn a lot, and I do mean a LOT. When I finish, I like to publish because there's a whole world of people out there who are waiting to tell me I'm wrong. Even when you get things wrong you have the chance to learn. The key here is that the focus is on me.

If I can help other people at the same time then that's just a great side-effect. Thankfully so far I think I've managed it on more than one occasion I do hope I do it again. But if I don't it isn't going to worry me, as I will have got something from the experience.

Thanks again, I'm glad you enjoyed the read. Have an awesome day!

I'm a huge fan of http://pointhq.com/

hook.io sits on top of Node.js and deals with IO. How on earth does this relate to Nirvana's goal of having something like Node.js for Erlang?

This is the most interesting point made so far. Agreed, I had not considered the likes of FSI. That does come with the issue of being painful reading XML config from app.config files, but can easily be handled via what we have.

Would you consider this to be out of the question:

    open CorrugatedIron.Comms
    
    let cluster = RiakCluster.CreateFromConfig("section", "path/to/file.config")
    let client = cluster.CreateClient()

Thanks again for the comment.

Your "protip" implies that "needed" is a known quantity, which it isn't in this case. It's a new project, new development without any clients at all. Personally, I would rather give too much flexibility and wind it back after a while than not give enough flexibility and have nobody use it because they can't configure it to their needs. The last thing I would want to have happen is for people to give up an attempt to use it because it isn't able to do certain things. That to me is not a protip if you're hoping that people will use it.

I wish I could post saying "Hey this has been proven on ..." but I can't, because it hasn't. My personal credibility has nothing to do with it at all. If you evaluate software purely on someone's credibility then you'd have barely anything to choose from.

For me, it's solving a problem that I have, and solving it quite well. From the feedback I've got elsewhere, others have felt the same and don't really have an issue with a typical XML configuration that you find in almost any .NET application.

While I appreciate the idea, I am not dumping the XML. It's idiomatic .NET configuration, and I am not going to fly in the face of this convention due to my, or any other person's, bias against XML.

You can specify the configuration through code, the XML-driven config is just one way that you can configure it.

I'm not sure which twenty lines of boilerplate you're talking about. I see 2 for configuration, and one to create a client. I don't see the redundancy, and I also don't see any of the configuration as useless. Each entry serves a specific purpose, and can be specified or left as a default (except for important properties such as host name). I don't believe that forcing hard-coding of configuration is a better option over XML, particularly in the ecosystem this library lives in.

> Read the rest of what I said.

I read it. Multiple times. And that was before I responded.

equark is saying that he doesn't want to write boilerplate code. You're saying that XML config is redundant and sitting around uselessly. I don't see those as the same thing.

If you don't work with .NET then obviously this library isn't targeted at you. Hence, feel free not to use it :)

Personally this difference of opinion is moot, as the configuration/wiring of settings is such a small part of the library. It is possible to configure it easily to fit your environment, even if it's 1 or 2 lines of code more than you'd like.

I'd be keen to hear what you had to say about the other 98% of the code. ie. The bit that actually does something interesting.

Thanks for the critique.

I agree with the point about the ConnectionFactory. That is something I still don't like. It's there, at the moment, to make it easy to test certain parts of the app. We'll look to add an overload to this so that we don't have to specify it for non-testing scenarios.

As a quick side-node something as simple as:

    var client = new RiakClient();

is nice, but has to infer a _lot_ from the world. We could write a lot of code to make sure that it's smart enough to pull all the details from the default locations or we could let people tell us where to look. We went for the latter, as it's much safer to be told than to pull config from the wrong spot.

Again, we'll look to improve this, particularly as we get more feedback from people using the library.

Thanks!

equark,

I don't think you were being overly negative. It just tends to be common for people on HN to be more terse than necessary and sometimes things can come across the wrong way. I have taken no offense :)

The sensible defaults thing is definitely something that should be in place. For v0.1.0, the goal was to provide the flexibility out of the box rather than the lack thereof. No doubt for v0.2.0 (already in the works) we'll have adjusted this to make it simpler for the more common cases. We didn't want to limit people out of the box.

Configuration of this kind of thing is hard when you can technically have multiple clusters, so somewhere along the way when wiring up the cluster you do need to specify something :)

At least we have the ability to do whatever we need. Now, with help from the community, users, and commenters like yourself, we can improve things to keep as many people happy as we can.

Thanks again for the comment.

jallman,

You're right, we are making a few assumptions, which to me is natural given that this is v0.1.0. It hasn't been used it production because it never existed before now.

I fail to see how enabling clustering and connection pooling via configuration is over-design. Perhaps you could share some more detail on that?

The first line of your code sample is making assumptions itself. No, you can not omit the parameter to RiakCluster, the section name in the configuration is not fixed and is configurable by the user. This means you can have multiple clusters if you want to and configure them both in your config and specify them by name in your code.

The last two lines are exactly the same as what we have.

So really the only difference I see in your suggestion is the way that the configuration is wired in. Here's where your assumption comes in: you have assumed that the configuration is always in the same spot (ie. an app.config or web.config). There are no guarantees that this is the case.

Yes, we could probably change the interface so that it does search common configurations by default, and that is a suggestion that we're more than open to. As I said, this is v0.1.0 and it's just been unveiled. After using it, I'd be interested to see if you consider the configuration/wiring (which is still quite small, and a one-off task) painful.

We seem to be quibbling over one extra line of code, which ironically is substantially shorter than the comment that either of us has posted.

Having said that, we are always looking for ways to improve this kind of stuff, as I too hate unnecessarily verbose configuration. In our case, for version 0.1.0, we wanted to make sure the ability to configure and wire up in many different ways was available. In future revisions we'll no doubt look at home we can make this simpler.

With all this in mind, along with what I said in previous comments, how would you go about enabling this level of flexibility in the library without, as you put it, making it "drastically over-designed"?

gecko,

Our design was not modeled on any existing library's approach to configuration. It was designed based on what we perceived the needs of the application to be.

I think making claims that the configuration is "ridiculous" isn't constructive conversation, especially when you haven't really backed up why you consider it to be so. After three lines of wiring, a caller creates a self-managing client instance via:

    var client = cluster.CreateClient();

I don't see how this can be considered ridiculous.

A simple comparison to one line of code (which, I might add, doesn't explain where the `configuration` variable comes from) is not really thorough. I'd be keen to see what it takes to get the configuration loaded and what extra boilerplate is required to handle and manage the MemcachedClient.

Thanks for the comment.

Hi equark,

Thanks for the question. Yes there are reasons why there are such differences between the CorrugatedIron configuration and that of the project you have linked to. To understand them, I think it's important to look at the differences between the two services being used, and the goals of the libraries that connect to them. Please bear in mind that I am no expert with Redis, nor the libraries that connect to it.

Production Riak configurations are clustered and hence it makes sense to distribute the connections across the entire cluster to avoid hammering one node. Clusters are often hidden behind some kind of proxy or load-balander such as HAProxy. Hiding behind a proxy is a great way of removing the need for clients to worry about the nodes that are in the cluster and managing their lifetimes.

In the .NET world I haven't yet seen many (or any) production configurations where there is a proxy, such as HAProxy install, sitting between an application and it's database. I'm sure there are many reasons for this, inculding built-in clustering for MS SQL (the most popular choice for RDBMS sitting behind .NET applications) or the lack of a cluster full stop.

When putting together the design for CI, we thought about what setup people are likely to have when they reach production. We came to the conclusion that there's a good chance that most people would be interested in reducing the number of "moving parts" and avoid the need to put a proxy in place just to load-balance connections across a Riak cluster. As a result, we decided to attempt to put this into the client library itself, hence removing the need to have a proxy installed. This doesn't, however, force you to do so. If you do have a proxy application which is load-balancing connections to your Riak cluster, then you simply have to modify the CI configuration so that there is just one node in the cluster and point it to the proxy.

This design allows both rich client and web applications to connect to the whole cluster without the need of a proxy. The "problem" with this design is that the cluster needs to be configured, and in the .NET world that is generally a little verbose.

The specification of the configSection is something that is required in .NET if you want your configuration to be included in app.config or web.config files. Forcing people to have separate config files would not make sense and goes against convention in the .NET world. However, if you do want to have your own configuration file outside of the usual locations, we support that too (just pass in the full path to the config file as an extra parameter to RiakClusterConfiguration.LoadFromConfig()).

Before embarking on the development of CI, we wanted to make efforts to reduce the amount of management that the user had to do. By management I mean handling the lifecycle of connections, freeing up resources, figuring out which node to connect to, etc.

The net effect of this effort is that once a cluster has been instantiated (which, mind you, should only be done once for the entire application's lifetime) the user can pull client instances out of the cluster and do not have to think at all about connection management. Getting hold of a client becomes as simple as:

    var client = cluster.CreateClient();

RiakClient instances are not disposable. RiakClient API calls, behind the scenes, use higher-order functions to avoid the leaky abstraction that is disposable resources and hence the RiakClient object doesn't have to manage connection lifetimes either. Get a client, use it, don't worry about cleaning up after yourself because we have that covered already. This gets rid of a log of fluff like:

    using(var client = ....)
    {
      client.DoStuff();
    }

.. and turns it into:

    client.DoStuff();

It might be just me, but I do prefer reducing "boilerplate" throughout the user's codebase and having just a little more in the up-front configuration than the other way around. This also gives us the ability to load-balance calls across the nodes in the cluster without the user having to think about it. Again, I think this makes the API cleaner, easier to use and reduces the chances of boilerplate leaking out into user code.

I think comparing this design to that which you have linked to, the RedisConnection, isn't really comparing apples with apples. But for the sake of discussion the RedisConnection, behind the scenes, obviously has some default values (such as port number) hidden away. We do the same, everyone but the node name and the host address has defaults behind the scenes and could be reduced to something as simple as <node name="foo" host="bar" />. This isn't hidden in the sample configuration so that people can see the options that are available to them. Also note how the user of this connection needs to know, in code, about the host they're connecting to. Of course, this could be specified via configuration too, but it has to go somewhere, and that will result in boilerplate. You're also managing the connection yourself, and the users of the client run the risk of leaking resources if they forget to clean up at the right time. Lastly, the RedisConnection doesn't appear to be pooled (please correct me if I'm wrong) and hence managing the number of connections to your Redis instance is up to the API user. In the case of Redis, this might be ok, but in production, it tends to be a good idea to limit the number of connections to services as network resources can be expensive.

So, just to reiterate, the design goals of both of these clients are obviously quite different. CI configuration is only done once up-front, and from there client instances are created simply by calling `cluster.CreateClient()`, management of resources is done for you, and it has built-in load balancing. Very different to Booksleeve from what I can tell (again, happy to be corrected).

I hope this helps clarify the stance and helps understand why and where the sacrifices were made.

Thanks again for the question.

OJ (TheColonial).

Webmachine uses Mochiweb behind the scenes, hence the reloader comes for free in this setup.

Distel is specific to Emacs. In this series I don't want to discuss which editor to use (esp given I prefer using VIM ;)) as that can come across as constraining. I'd rather leave IDE/Editor discussions elsewhere.

Details of this is coming in a future post. The early parts of the series are focussed on the development environment set up :)

The company thing still comes with a caveat in that you have to prove that you're not just using it as an umbrella to reduce your tax. There are a set of tests that a company goes through at tax time, and they have to pass them in order to be considered a proper company (the 80/20 rule is one of those tests).

Conditions aren't the important bit imho mate. The important bit is that you can still be got rid of fairly easily (unless you work in the public service, which seems almost impossible to be fired from). In that regard we are quite diff to the UK and more like the USA.

Forced redundancies are indeed uncommon at the moment, but I think that'll change. They weren't too uncommon just a few short years ago either.

Yes, for the right job, or for something they love, they would do it. I know because I have done it.

I went to the UK in 2004 to do some travelling and working for a couple of years. Initially I was contracting in London at pretty good rates (between GBP 400 and 600 per day -- as I said, in 2004). The first year of contracting I earned just over GBP 120K. That's approx. USD $190k on the current exchange rate.

Part of the reason I went there was because I wanted to take a stab at the games industry. It was something that I had always wanted to do, and the industry here in Australia was awful. So I took at job at one of EA's studios.

That year I earned GBP 27k, approx. GBP 90k less than the year before.

Do I regret it? Not at all. I had a blast. It was a great experience and I met some amazing people.

So no, it's not all about the money. For the right gig in the right place with the right level of passion, earning enough to survive is exactly that: enough.

OJ

Correct mate, I am an Australian. I would say that our job security level is closer to that of the USA than the UK, but I don't think it's exactly the same.

On the whole I've seen way too many good people let go from permy positions while other plebs are retained. In same cases there doesn't appear to be any rhyme or reason to who gets culled and when. To me that's a real sign that the "important" differences between permy and contractor are well in favour of the latter.

Cheers!

Apologies to anyone who has struggled to hit the site. It's not used to this level of traffic!

I'm enjoying the discussion too, thanks for the insights!

OJ

This kind of post is what killed Slashdot. Please don't do it to HN too.