adlawson

Interesting project! May I ask why you chose ClojureScript over straight Clojure?

My understanding of ClojureScript is that it's Clojure syntax for a simple single threaded environment (probably an oversimplification), but with Golang you have a lot more reach in terms of concurrency.

Please forgive me if I haven't phrased this very well. I certainly don't mean to put a negative spin on this or anything; I'm just curious.

While I agree it's not smart to put all your eggs in one basket, you don't need loads of job offers to land the job you want. It only takes one.

I've thought of doing something along those lines, but haven't done anything about it yet.

If you'd like to contribute the changes or submit ideas that would be great. Don't worry if you can't or don't want to though!

(OP) I've been maintaining this repository of language Vagrantfiles for a while now, but I'd like to see the number of supported langs and number of active maintainers increase.

I think that one of the most difficult barriers to trying out a new language is the initial setup. Some sites like golang.org and haskell.org let you play around on the homepage, but it isn't quite the same as having a working local environment.

Anyway, thanks for any support you may offer.

I've been looking for something that's both useful for me personally to check out the current work available and that works as an employer. I think this is it.

It's incredibly difficult as an employer to convey exactly what the job will involve. Unless you're hiring a direct replacement of somebody you likely won't know what it is they'll be working on. Equally, as a developer, it's easy to see a job spec as a pack of lies, which they often are, and it can be hard to break into a slightly different role. A recruiter's aim is to fill the jobs their clients are paying them to fill and not to advance careers of candidates. I believe this [will] solve the problems in the current recruitment industry from the perspective of both invested parties.

I fully expect this to stir the waters of technical recruitment, so best of luck to you both.

Chris Boardman, an Olympic cyclist for GB, recently appeared on BBC News to talk about cycling safety while not wearing a helmet during his demonstrations. He gives his reasons in this short video https://www.facebook.com/video.php?v=974497519231053&set=vb....

I certainly don't disagree with him, or with you, that there are plenty of other safety aspects to consider while cycling, but I'd always wear a helmet anyway.

Just something I did a few days ago, mostly for a laugh.

Feedback and contributions are welcome, as always!

Thanks - you're a lifesaver

No assumption, just offering another way to install.

Maybe just chill your beans and enjoy Peter's writeup.

If you'd prefer to play with golang on linux, I've got quick a Vagrantfile ready to go at https://github.com/adlawson/vagrantfiles

    curl -O https://raw.githubusercontent.com/adlawson/vagrantfiles/master/go/Vagrantfile
    vagrant up
    ...

Location: London

Remote: Possibly, not necessarily

Willing to relocate: Yes, for the right location

Technologies: JavaScript/Node, Golang, PHP, (interested in exploring others)

Resume: https://github.com/adlawson http://linkedin.com/in/adlawson

Email: adlawson+jobs at gmail

Thanks very much :)

You write your php to a file in the vfs, then you `require` it back out. There's an example of it in the documentation[1] but a simple example could be:

```

<?php

FileSystem::factory('vfs://');

file_put_contents('vfs://foo.php', '<?php echo "Hello, World!";');

require 'vfs://foo.php'; // Hello, World!

```

[1]: https://github.com/adlawson/vfs.php#documentation

I don't see why not. It only loads a few objects into memory so the footprint would be tiny, especially when you compare it to running WP.

If you can configure the paths these plugins write to, then you can use VFS. Unless the plugin explicitly uses `file://` or they strip the scheme, but I doubt they would.

On the surface of it, there is no real difference. You can use them both with your usual `fopen` and `file_get_contents` builtins.

I believe that the implementation is truer to the behaviour of how these builtin functions behave with a unix FS. Amongst some other subtleties, here's some examples:

- vfsStream simply ignores handle modifiers (except for +)[1]

- some effort has gone into showing where errors were triggered in userland code[2]

- node types are represented as `fstat` would see them[3] rather than using simple types[4]

vfsStream works perfectly fine, but if you want to use it more with testing file system operations; the closer you are to a true environment the better. Obviously this project isn't quite there yet, but it should be once a few issues have been ironed out.

[1]: https://github.com/mikey179/vfsStream/blob/master/src/main/p...

[2]: https://github.com/adlawson/vfs.php/blob/master/src/Logger/P...

[3]: https://github.com/adlawson/vfs.php/blob/master/src/Node/Sta...

[4]: https://github.com/mikey179/vfsStream/blob/master/src/main/p...

I absolutely agree with you about applications using their own DI/IOC implementations.

The registry in this library, however, isn't meant to be a registry used outside of the internals of the library. It's an unfortunate side effect of trying to marry up object instances with PHPs static stream wrapper API.

I know PHP isn't the "coolest" of languages around, but I thought I'd just show my project I started a few years ago and never really got around to finishing.

It's been used before as part of a mustache template runtime evaluator and in test suites.

Current issues:

- Test coverage is okay but could definitely be improved (currently ~60%)

- Symlinks

- Proper support for perms/ACL

If anyone's got any feedback or wants to contribute, go ahead.

I'm not really sure what point you're making with these remarks, but it does come across as rather biased.

It is entirely possible that some of these "Adria-Richards-esque thought police" developers, as you call them, weren't very good, but labelling Rowan or the contributors as incompetent is just plain ignorant.

My counter to your comment is that if you want to hire developers who's performance is based entirely on the lines of code shipped, then that's your prerogative. I, on the other hand, prefer to hire developers who can think for themselves, who have the motivation to be creative with their work, and who like to involve themselves in other projects.