andrzejkrzywda

The book ad was there almost from the beginning, so we've assumed that the contributors are aware of the way this repo is funded.

As for sponsoring other products/companies - we'd need to see if it's aligned with our goals and with our target group. I don't remember anyone approaching us so far.

It's not a classical open-source project, but what we did with our React.JS koans (and other our OSS repos) was to advertise our React.js book in the README and give a discount code. Essentially, it's an ad for our own book.

https://github.com/arkency/reactjs_koans

Thanks to this solution we've had more money to work on this and other OSS projects.

Async standups may be a good alternative, you can do them over email or on Slack/Hipchat/Flowdock.

Different rules apply in async standups than in meeting-like standups. There's more focus on what your daily status can bring to other people.

I wrote about some tips here: http://andrzejonsoftware.blogspot.com/2014/05/async-standups...

I didn't consider and test KDP, so I can't say anything.

As for Leanpub:

1. Last time I checked, they didn't let me take the customer emails and use outside of Leanpub. I find it a very important limitation to the way I do the marketing - via my mailing list. In practice, my readers are more Leanpub customers, not mine. I want to build long-term relationship with my readers, to deliver more value to them, even after they bought my book. To be fair - Leanpub has their own tool for sending emails, I haven't tried that. I'm happy enough with MailChimp, not to see reasons to switch.

2. From the tools I researched, Leanpub is the best when it comes to PDF/mobi/epub generation. It takes a while to learn their process but it was worth it.

3. I'm really grateful that Leanpub allows the process I'm doing - generate the files using their tools, but selling on another site.

Overall, the tools you're choosing should fit your whole process of researching, writing, marketing, selling.

As someone who has just recently started writing programming books [1] I'm really excited to see more such tools!

Some thoughts:

1. Code examples are the biggest problem to me in the tools that I tried. There's many little things about them, that need to look right - line numbers, display on kindle, line breaks

2. At the beginning, I've used Git and vim for writing in Markdown. However, at some point I realised that I wasn't efficient - I switched to Scrivener [2] and dropped the idea of using Git. In my case, it made me much more productive.

3. Writing an ebook is different than writing code. You probably don't need much of the history.

4. Research is for me the biggest part of writing, experimenting with different ideas, collecting code samples. It's good to have a proper tool to support it. In my case, Scrivener [2] was a huge improvement.

5. I use a combination of Scrivener, Leanpub, Dropbox and getdpd [3] for the whole project. Scrivener for research and notes organisation, Leanpub for generating the result files (PDF, mobi, epub), Dropbox for syncing those two. Getdpd for the selling part.

[1] http://rails-refactoring.com/

[2] http://literatureandlatte.com/scrivener.php

[3] http://getdpd.com/

If anyone's interested in a more real-life example, then this post presents a Rails controller refactoring from the Redmine project.

http://blog.arkency.com/2014/02/rails-refactoring-the-aha-mo...

I recommend watching Greg Young's talks on DDD/CQRS

http://skillsmatter.com/expert-profile/open-source-dot-net/g...

It's essential, but also ... difficult.

It's a peopleware problem, more than a technical one. If there's no trust in the whole team, then all the design/architecture challenges are less important.

I've just read it today, a good post on this topic:

"We all know Conway’s law: “any piece of software reflects the organisational structure that produced it.”. In the same way, communications patterns between people affects the quality of the software. After 6 months working on a greenfield project I realised I could link all the areas with major technical debt to some unsolved personal conflicts in the team."

http://bitlyfied.com/2013/12/19/happiness-and-other-technica...

I'm sorry! It's fixed now, thanks!

I fully agree with the risk that certain ideas will be overused. This leads to unnecessary complexity. I also remember the times of the GoF book and the design patterns rage.

The ideas behind those architectures require time to think through. The sooner you start, the better. Then, slowly, try adopting them. If you have a side project, then apply it over there.

It's crucially important to have a common understanding of the project within a team. The domain knowledge should come from the subject matter experts, but after that it should be a team work to decide which (if any) patterns and architecture should be applied.

This kind of chess battle doesn't happen very often. We can compare it to Fisher-Spasski or Kasparov-Karpov.

If Carslen wins, this will be a generation change in the chess world.

Given the popularity of chess in Asia, it is estimated that about a billion of people are following this match[1].

[1] http://www.gq-magazine.co.uk/comment/articles/2013-11/14/mag...

"Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it."

I've seen so many of such bugs in other apps, that I treat them as part of "ActiveRecord price".

ActiveRecord over-usage makes it very easy to miss the places, where queries need to respect new rules.

You're doing an awesome job with Discourse and the team approach to such bugs is very good - no doubts here. Thanks for your work!

Choosing a heavier framework may put you in risk of 'typical', framework-related bugs that often appear. The bugs are not part of the framework, but they are part of the patterns around it.

Discourse 'private topics' leaks (1) are good examples of typical security Rails apps bugs (the result of overusing ActiveRecord). I'm not blaming Discourse, the same kind of bugs appear in other popular Rails codebases (Diaspora, Spree, Redmine).

Ember.js is very Rails-like. I didn't use Ember much, but the patterns look so similar, that it may lead to similar kind of problems as in Rails apps.

I'm not saying that we shouldn't use Rails or Ember. In fact, I'm a big fan of Rails. It's just worth being careful of not falling into the trap of overusing the framework patterns.

The frameworks are best for the infrastructure parts of the app - http, persistence. At the end, it's better that you can control your models. That's the part of Angular that I prefer over Ember - you own your Model part.

(1) http://meta.discourse.org/t/digest-mail-ignores-secure-group... http://meta.discourse.org/t/non-authenticated-users-see-priv...

Think of the router as the "main" method of your application. It's passing you the initial arguments. You just parse it and run the correct logic and/or display the view that is required.

We all expect to find a Rails/Django equivalent for JavaScript apps.

There's nothing like that.

All of the JavaScript frameworks are in their infancy. It doesn't mean we can't use them yet. It's just that they are not mature enough to be easy to use.

Sounds interesting. I'd be interested to see some screenshots of how you approached the problem.

All the code review tools focus on commits, which is probably the most common use case.

Is anyone aware of tools that let me do the code reviews of the whole code base in a simple way? I don't want to focus on the commits/pull-requests in this case.

This presentation reminded me of this:

Sometimes it's better to hire a younger, less experienced developer, who's not aware yet, that "specialisation is good". Thanks to that you can have one dev who's able to finish the whole project. Obviously it's only true for smaller projects.

You are right that there is a danger in the fact that the object being passed into the AOP advices can be changed.

Usually, I'm avoiding this kind of situations. It can be terrible to debug.

In our teams, we have a rule that the calls to Before/After/Around can only happen in the Glue code.

Obviously, we also make sure that everyone involved is familiar with AOP and knows what is the architecture.

As for the use cases for AOP, I know it's not a common practice to use it. Orthogonal concerns are the best fits, but not the only ones.

There was an interesting research project at IBM, called Hyper/J. It was a little bit of inspiration for the AOP usage in the hexagonal.js architecture.

Here is a good paper on Hyper/J (and the idea of Multi-Dimensional Separation of Concerns)

http://helios.mm.di.uoa.gr/~anya/pms521_papers/p734-ossher.p...

Thanks for your comment, it was very valuable.

In runtime, this is exactly the result.

As code modules, those two things are separated. The usecase doesn't need to know about the gui and vice versa.

In theory, they can even be reusable.

We combine those two things in the glue code. Thanks to the glue code, it's the usecase which drives the other things. The usecase makes sense even without thinking about a specific GUI solution.

I'm not sure where we could put the second piece of code you mention. Any suggestion?

We were struggling with this problem for months.

What would you suggest to bundle into this library?

We're going to include pure JavaScript examples. I understand the confusion that comes with the fact that most examples are CoffeeScript.

There's nothing that makes this approach impossible to use with JS. The code samples are Coffee, because that's what we write our production apps in.

Thanks for the link. I wasn't aware of this discussion.

Yes, it seems that hexagonal.js uses the third approach - a metadata file.

This.

I'm one of the people behind hexagonal.js. Raganwald's work enabled us to implement one of the main components - the glue code.

> 3. Yes we render a lightweight version of the pages in a <noscript> tag for google indexing.

Can you explain it in more detail? Are you returning different results to Google bots?

The official documentation is here:

https://developers.google.com/webmasters/ajax-crawling

The best way seems to be returning different results to the Google bots. It's recommended by Google.

It's not as much pain as you would think, it's enough to just return some html. No css/js is needed.

Still, that's some additional work.

It may help, if we focus on some specific examples of CLA-X and CLA-Y.

Rendering html on the backend was the only option for years, as the clients didn't have the computation power. Now, we're getting to the point, where rendering client-side becomes possible.

We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server.

We can (and we do) have separate teams working on client/server. It wasn't that easy before.

I'm 33, if that makes my comment more legit ;)

It's not all or nothing.

You can do what Twitter did. Allow some duplication and render html server-side on the first request.

It's both simple and revolutionary.

It starts with saying "well, let's just render html on the client-side instead of on the backend". Suddenly you're in a new world of programming.