I have yet to figure out if this will be a good thing for the front-end.

One of the strengths of node modules is how it deals with the dependencies for each module; and that is to keep each module and the modules it is dependant on in a separate package.

That's a lot of utility libraries

This can lead to duplication in a project. As two modules can both have a dependency to the same module but each package for those original two modules will have it's own version of the dependency included.

This can result in duplication in the final version of the product being produced.

As of writing (28th August 2014) there are 91 472 packages on npm; and of the top ten most depended on packages underscore and lodash (two utility libraries that have a common API) are depended on by 11 647 packages (6937 and 4710 respectively). So just over 12% of the packages share this dependency and each package includes it's own version of underscore/lodash.

Version was an important word

One of the advantages of each package having it's own dependencies is the version of the depended on module does not matter. e.g. moduleA could require lodash 1.1.1; while the newer moduleB uses lodash 2.4.1.

In the node world this way is working!

Server side this works great. Everything is kept clean and separated. The advantages of this approach at the server (and local development) side greatly outweigh the costs of duplication.

Will this work for the front-end

In the front-end world of concatination and minification. The costs of duplication seem higher. More data being passed down the wire, more for the browser to process.

As with many things in the development world its striking that balance between the advantages a technology brings versus the costs.

So long term another technique could be used for smart reusable clean modules.

To use this node style technique in front-end development, while trying to minimise the costs of duplication, will require restraint from developers. Restraint from front-end devs to decide on a case by case basis of the costs of adding a new module.

I recently thought of a tenuous link between Chrome DevTools and Starbucks. Starbucks set itself an early goal to become the 'third space', the space a person would spend time between work and home.

and now for the tenuous link

In my development Devtools has become my third space. Between the source and the output. You'd write some code, check the output and based of the result, you'd go back and update your code. Back and forth a binary existence of either coding or assessing results.

With Devtools I now have a third space, and for me my most important space as this is where I do my thinking. As it gives me hooks into the three areas that make up a website the DOM

theoretical next step

So the next step would be to start saving the changes I'm making in Devtools. Which is where workspaces come in, the ability to map the files delivered to the browser to it's location on the disk, allowing the source files to be edited.

However the files being delivered to the browser are not always the source files that need editing. Pre-processors for CSS and JavaScript are extremely helpful in development but this adds an extra layer between the source files and the workspace. This is where source maps come into play. To bridge that link between the delivered files and the source files.

and in anger?

Reading Remy Sharp's blog source maps may not be the answer quite yet for JavaScript but I plan on testing workspaces, source maps and browserify together. Its in the 'would be nice' column to add to my workflow. The one that 'would be great' to add is CSS.

So I'll grab a coffee set up source maps and workspaces see how they work, try and blur the lines between spaces and report back.

quick hello

I did get a surprise after I set-up the group. I got an email from meetup HQ giving some advice on running successful meetups and then at the end of the email a 'p.s.' just to let me know they'd updated the topics attached to the group. I checked and saw they'd added 'tech talks' and 'education and technology' to the list of topics. Which I thought was excellent (although maybe a bit ambitious to start off with). They did also mention one fact in the email that meant I had made a small miss-calculation.

live and learn

I set the meetup site on a Tuesday. Thinking that it would be sent out to meetup.com members right away. This is not the case, they actually wait 4 days before posting it out. So rather than the notice being sent out midweek, it will go out just before the weekend. I do like the window though, gives you an opportunity to get the page set-up fully, while at the same time giving you a ticking clock incentive to get it done.

what next

Hopefully get a few members over the next few days and schedule the pre-meetup. Go down the pub (probably), and see what we can turn Devtings into.

If you go to meetup.com and search for developer meet-ups, depending on where you are in the country you will see dozens of different meet-ups available for all flavours, variations and discipline of developer. With one small caveat the majority are based in a city.

As a developer who would like to talk to other developers about development, this posed a problem for me. Being based in Hastings the amount of time it would take to travel to these meet-ups made attending any very difficult. So I had an idea; Why not set-up a local developer meet-up. A developer meet-up in Hastings, so devtings.

That's as far as I've got so far, an idea (and a domain, and an IRC channel). This blog post will be about the thoughts and assumptions I've had regarding the setting up the meet-up, and as we move forward my plan is to blog about the reality of it.

meet-ups in theory

One of the things I have realised is that a local dev meet-up can't be the same as a larger meet-up. Firstly you can't be too specific in your topics and audience. A meet-up like Functional Brighton would be too specific to build a regular meet-up around, however talks and discussion about functional programming would make a great contribution. A good model I think for this is podcasting. A podcast like .Net Rocks! will cover various different aspects and disciplines of development. Then with guest experts to deliver some deep insight into the topics covered.

presentations

With a local meet-up it will be more difficult to get a wide variety of industry experts to come and give presentations. But there is opportunity in that as well. There will be people who want to be industry experts, who want to be a presenter at conferences a local meet-up would give them a place to practice, develop their skills and hopefully be a stepping stone for them. The other opportunity is for regular members of the meet-up to give their own presentations. Again this gives people an opportunity to develop their own skills and confidence.

Other items of business

Although the presentations will be an important part of the meet-up, they will not be the only part. The meet-up should be a relaxed environment where developers can discuss anything they want. Structure is important so people know what to expect but at the same time things need to be flexible and if this is going to be a successful venture it needs to grow organically.

How much is this all going to cost?

The costs of a meet-up. Costs are something that can grow and grow quickly. Starting off with organisation; you need an online presence you can point people to. Then with a place people can go it needs to be followed up with some promotion. Venues, food and drink, guest speakers; all these things cost money. So while this idea is getting off the ground we'll ignore the more formal ideas. Keep costs low, see if there is an interest and build from there.

what we've got and what we need

So far we have a domain (devtings.net) and thanks to Alex Hitchins an IRC channel #devtings.

pre-meet-up-meet-up

So far I've floated the idea to a few developers I know and work with and have got a positive response. So the next step, it's to get a few more devs and go to the pub. Start fleshing out some ideas, see what others can contribute and lets take a bunch of devs living in Hastings and start building a community of developers.

• CSS
• Bootstrap

Something I noticed while digging around in bootstrap was how they added a point to a dropdown menu. I thought I'd demo a simplified version of the steps to get there. In Bootstrap the point is created using a pseudo element and also takes advantage of

1
2
3
4
5

1. Start with an element (div) and add a border
2. Each side of the border is connected at either end by a mitre joint. This is what is taken advantage of To create the pointer look.
3. The height and width of an element is the internal size of that element, the border is calculated on top of that. So the border will still be drawn even when the height and width are both set to 0. I've also increased the size of the border here.
4. Final step is to make 3 of the sides transparent and the

background-color

1
2
3

You don't have to have an equilateral triangle, by changing the widths of the 2 adjacent sides you can create a variety of triangular shapes. The demos all have a

border-top-width``` of 20px.

The talk starts by looking at the web in 2003 and a compares it to the web in 2013. This was just the background and foundation to lay out the ideas of the indie web and the future of the web.

The bit I found really relevant

When Marks was discussing the future of the web one of the points that resonated with me was about building tools that you want to use. I think this idea will colour most of the decisions about how this blog engine is developed (for now). It's easy to go down a rabbit hole of second guessing what other people want in a tool. But while it's just me, I'll stick to a few rules of thumb:

• In the core development, I'm not going to worry too much about breaking what I already have.
• With one big caveat, when I update the the distribution version of the engine that is powering this blog I'm not going to overwrite any theming or content I already have here.
• Going from writing a new post to publishing, I want that to take minimal steps. Ideally one but I've not decided on grunt powered commits.

Bonus Feature

Here is a follow-up interview with Kevin Marks where he discuss and expands on some of the ideas from his presentation and gives a bit of background on the history of video and the web.