Community/Dev Blog

[Merelleya]

Conceptualization

• Content Plan
• Editorial guidelines
• Editorial workflow
• Reach out to possible contributors

Implementation

• Decide on a cms
• Design/branding
• Integration into the website

---

Apart from the showcases, we would like to have a community/dev blog where we can publish articles about what we are working on, features, unusual things you can do with haxe and have guest posts from members of the community.

I would love to have that integrated into the website, since it is editorial content and I don't want the traffic to go elsewhere. @jasononeil this is something we can add to the list of things to talk about tomorrow.

Please comment so that we can come up with a concept and relevant categories/series

[Simn]

I just wanted to check how much time it would take me to write a bit about my development thoughts. I wrote this in 30 minutes, it's obviously not edited in any way but if you think this might be interesting I can do it on a regular basis:

Conference aftermath

A gettogether of most of the Haxe compiler team as well as a lot of smart and creative community members comes with some side-effects in the form of new ideas. Not all of these ideas work, to be sure, but it is evident that many people spend a lot of brain processing power on how to improve the compiler and everything around it.

Static analysis vs. C#/C++ improvements

On Sunday evening I had a very interesting talk with Caue and Hugh about their targets. In particular, we talked about some similarities of the C# and C++ targets and how we can improve in this area. Hugh had just before introduced ways to represent native pointers and references over which I had concerns regarding static analysis. Let's look at a small example of what a compiler can do with constants:

var x = 1;
call(x);
trace(x);

It is very easy to determine that the value of x is going to be 1 for both occurrences. That value is assigned to it and no other assignment is made at any other point. It is also not possible for either call(x) or trace(x) to modify x because it is passed by value. The compiler then happily changes the output to this:

call(1);
trace(1);

However, this is no longer true once we introduce reference or pointer semantics, which is precisely what the new C++ feature allows. In that case we have to conservatively assume that the value of x might be changed by other parts of the program, e.g. during call(x). As a consequence, the static analyzer has to know about these semantics.

Macro in macro in bar

The day before we had the official Haxe party where Nicolas explained to me the problem with macro-in-macro by shouting at me over loud music. It made for an interesting experience but I wasn't quite sure if I got it. His argument basically was about infinite recursion: If a macro is processed and calls another macro, which in turn calls another macro, which in turn... You get the idea. While that can certainly be a problem, I didn't understand why this would be different from normal infinite recursion. At least not for normal expression macro where surely you can avoid this via control flow just like you normally would.

Thinking about build macros in this context is more interesting. How can we avoid a build macro in a build macro recursing infinitely? This seems to be what is currently blocking the support of build-macro-in-macro and we have yet to find a good solution.

Static extension operators

Juraj Kirchheim reminded me of my suggestion to allow operator overloading by statically importing them just like you would with class fields. I still think this is a great idea: All operator overloads are local to a module and thus easily discoverable and you don't have to decide if you put your Matrix * Vector operation on Matrix or Vector. I said I would look into it after WWX, and I did!

The basic implementation wasn't very hard but I soon realized that we would have to decide on whether or not we want to allow overriding built-in operations such as Int + Int. On one hand it would offer more flexibility, on the other hand it might lead to some major confusion. In fact, it already did so in the haxe.Int64 module when it turned out that Int could be assigned to Int64 and some unintended overloading was going on.

It is probably better to not allow such things, but then this requires us to first check the built-in operation and only resolve overloads after that. Unfortunately the current operator handling is not exactly designed to be recovered from, so this is going to require some more work.

[larsiusprime]

I think a community blog would be swell! I think we should encourage people to re-post their normal content there, so we could get the latest from OpenFL, Kha, SnowKit, NME, etc, which generate pretty nice little articles from time to time, and it could become a great central repository for people wanting information on Haxe.

EVEN BETTER, with the permission of the content's author, we could use the "community blog" re-post of a particular item as the thing we trot out during social media magnification rounds, so that incoming traffic naturally spreads around rather than clustering in one place.

[Merelleya]

I do not want re-posted content because it causes SEO problems and all sorts of other issues. If we are talking about paraphrasing, summarizing or some such, that would be good. Also, content collection is what we have the round-ups for. I am not averse to having feature posts or guest posts from other community parts, though.

A blog is not a good platform to re-share content, unless it is embedded as supplementary information in another unique article. What we can do is schedule particualrily important articles for re-sharing on social platforms (I use buffer for the purpose, so I could, for instance, set up your "Flash is dead" blog post to be re-shared in 6 months).

@Simn I LOVE! Do you think I can get one of those each week or every two weeks?

@jasononeil We really need that blog....!

[hughsando]

Re: Static extension operators - without trying to start a flame war or anything, what is the logic behind wrapping operator overload in an abstract (or static extension), rather than directly on the class. This seems like one extra step without which the static extension would work as-is without modification.
If we are looking to make this more part of the language, then maybe it is time for the "operator" keyword.

[nadako]

Static extension operators could be nice for structures, but other than that I can't see a fair use case for it. If you're writing vector class, you'll add add/sub/mul/div methods into it and it feels confusing to have to add using to make operators available for that. I mean, try explaining that to your average non-haxe-fan colleague.

Are there any problems with adding operator overload to classes besides Dynamic and name clashes? I think that could be solved if we introduce reserved _hx_ prefix (see HaxeFoundation/haxe#4246) and just reserve method names for operators, it would be possible then to generate okay-ish code for Dynamic case as well.

[dogles]

@Simn It would be AWESOME to have these little windows into development on a regular basis, and I think it would provide great optics for Haxe. It's incredibly worthwhile to show potential users that there are people actively working on the project on a daily basis, solving interesting problems.

[delahee]

@hughsando ftagh'n issue hijacking spotted, please don't unleash some unspeakable soul eater on Jo's domain :D

[Simn]

@hughsando: Please use HaxeFoundation/haxe#2803 for a discussion on the subject itself, I really only picked some topics to write about here.

[elliott5]

For those of us without the inclination to read through all of the past and present issues on each of the HaxeFoundation's github repos, a regularly updated community dev blog, containing original material which summarises the current dev situation within the Haxe ecosystem, would be a really helpful. It would allow new or peripheral Haxe users (like me) to understand the present state-of-the-art more quickly, and therefore use the full capabilities of this world-class software development environment, which in turn will lead to more people using Haxe.

I found the discussion above very interesting. If that is the quality of discussion we will find in the dev blog, it will be well worth reading.

[hughsando]

Sorry, I mistook the meta-discussion for a discussion. Must have forgot the macro tag.

[Merelleya]

The results of this morning:

• yes we want this blog and sooner rather than later
• I want it to be integrated into the website
• it is ok to use a third party cms if it can be integrated, rebranded and it means we get it going sooner
• we can think about a Haxe-Powered cms as a future project but I really don't want to wait with the blog till we have one
• the requirements are normal blog features such as:
  • categories and/or tags, authors, dates, etc
  • maintainable SEO friendlyness (nice links, meta information, etc)
  • easy to edit and previewable
  • should permit scheduled publication
  • photos/videos and formatting (nice quotes, whatever)

We can discuss some editorial guidelines and possible topic categories as well as technical aspects so that we have a clear idea of what to do once Jason can work on it after the 20th of June.

[Merelleya]

Things we could start on:

• compile a list of possible "serials" (like weekly updates)
• compile a list of contributing authors (regulars, maybe)
• reach out to possible authors
• look at cms solutions

[ncannasse]

ok for all these things, we have to find a good balance between communication aimed at the existing community (which seems is lacking given the misunderstandings we got) and communication aimed at new haxe users to explain them how great Haxe is. The blog should have both types of content IHMO

[Merelleya]

@underscorediscovery suggested we look at ghost.org

[larsiusprime]

+1 for ghost

I use ghost for fortressofdoors. It's great, looks good on mobile & desktop, easy to theme, easy to use, and uses markdown input syntax with a live preview. I happen to have mine hooked up to a discourse forum to power comments (discourse also uses markdown which is super convenient) but that's optional.

[ruby0x1]

Re: ghost,
I also noted that it allows embedding custom js/html in any post. I use this extensively to provide post-specific information or functionality, embed web builds of games, and so on.

Ghost is also transparent, open source, and can be easily self hosted on any server.
It also runs really well, I've had posts hit front page of major sites without peaking over 2% cpu on a $10 VPS. I use it for 5 community driven sites, for content publishing, it's a really great option.

Fiene says: thank you so very much

[Merelleya]

I will include this in the description of the issue. We should expand on the sub-tasks as needed.

Conceptualization

• Content Plan
• Editorial guidelines
• Editorial workflow
• Reach out to possible contributors

Implementation

• Decide on a cms
• Design/branding
• Integration into the website

[markknol]

+1 for blog.haxe.org

Do we want it to be part of the website, like the manual, or separate but in same style like the api docs?

Q:

• Can we easily allow multiple users in the blog?
• What format/editor does it use? Markdown or just html?
• Can you schedule posts?
• Wouldnt it be an idea to make the roundup haxe.io site be part of this blog?

[Merelleya]

Hi Mark,

specifications are further up. It is to be part of the website. Also almost everything you mentioned is listed in the features that I wanted. I think ghost.org allows for all of those, If my first cursory glance was any indication. It uses markdown.

I can talk to @skial about the roundups again but our last consensus was that we would feature them prominently, but that he would keep them at his place.

[waneck]

About a pure haxe solution, I've made a little project some time ago for a
personal blog. It's at http://codegen.ml , and its code is so simple it
barely needs a library. The code is at https://github.com/waneck/codegen.ml
, and it generates static htmls for each blog markdown file, and I've setup
a github hook so it regenerates every commit to master. I'm still not happy
with the awkward github comments thing, but we can use disqus or Facebook
comments

[waneck]

Okay, I've talked a little with Fiene about this, and if you want I can make a custom Haxe solution using the codegen.ml code and make it functional today.
There are I think two things from Fiene's list which aren't done right now, and they are:

• Scheduling posts: I'll make a custom cronjob which will hourly check for new posts, and add a mechanism to include a meta-tag to schedule them for a specific date
• Previewing posts: This is actually possible with a local cloned repo and a simple webserver, like nekotools server. I'll write a wiki post on the github page if you agree with this

We'd need to adapt the layout to a more Haxe-oriented one ( @jasononeil any comments? ) . I'd love to hear comments about this solution vs using ghost, and if you guys are ok with my solution, I can make it online with everything working (in a 128MB server) today

[dogles]

My only concern with the custom solution is that maintaining/extending to it will continue to subtract time down the road. Is there any big advantages to this over using something like ghost? We use Wordpress for our blog (http://proletariat.com/blog) and it gets the job done reasonably well.

[Simn]

I don't have a strong opinion in either direction but I trust waneck can build something that does not require ongoing maintenance.

[ruby0x1]

I think it's a monumentally bad idea to roll a hand made solution for a blog if the point is frequent or consistent updates. The more effort (no matter "how little") to create and publish a post, the less it will happen. Short, mid and long term in my experience it's a waste of time and will negatively impact the goals.

[larsiusprime]

Have to agree with Sven here -- keep it simple, remove all friction that keeps you from posting.

[waneck]

I don't know, every time I've used a custom blogging platform, all I had were headaches. From having to code in (ugh) PHP, lousy security/performance (which leads to the need of constantly updating it), to hard customization (lots of templates to change, features you don't need). In my own view, there is little reason to use a blogging platform for something that simple - specially if you know markdown and git. It took me a day to put the whole thing online, and this was still counting the time to actually make the HTML/CSS - which is a small fraction of the time I spent last time I tried to modify a wordpress theme.
This solution generates static pages, pre-gzips them, and it only allows people who have access to the git repo to change its contents. I've done a lot of testing with that 128MB VPS server, and it has handled all load I've tried to put into it. In a very small server. Also, it loaded the page in record time :)

Anyway, I'm alright if you feel it's best to use a prebaked solution (and I agree that I'm looking at it a lot from the technical side) - but we should delegate to find who will handle this.

For reference, check http://www.webpagetest.org/result/150606_V7_K9H/ to see how well the site performs now.

[ruby0x1]

Comparing against wordpress is a joke :) I would also suggest literally ANYTHING else - even mailing hand written letters to every reader on parchment is better. I didn't suggest wordpress for that reason, it's complete garbage.

Currently what you're suggesting though does not answer any of the needed features mentioned above. Multiple users, etc - I don't see ANY of that in the suggestion, sorry. Not without redoing a lot of work that i am fairly certain won't line up with the likes of a large team over a year+ of hard work (in the case of ghost).

In the end, whatever is chosen affects the community (users), and most definitely affects the person whose shoulders the work falls on. I'm guessing it's not the person hacking together scraps of code and markdown to make this blog make sense.

I'd say the opinion of the person/people who will have to suffer the workflow should be the most weighted, because you're picking either their pleasure or their pain. Every pain point is one less reason to care about this at all in the end, technical or otherwise.

[Merelleya]

Let me just summarize:

• we have considered ghost.org
• we have considered @waneck 's solution

ghost.org is an open source project and also seems to support all the features I asked for. I can not comment as to its usability, since I have never used it before.

Caue is confident that his solution can support all the features I asked for as well and it would be made in Haxe.

Since the persons who will work with this will be mostly @jasononeil and myself, we will review this based on the facts provided and then go with whatever we feel most comfortable with.

I think there is a partial misunderstanding because the topic is named "community blog". Other than the occasional guest post, the community will not have to work with this blog. This is mainly a Haxe Foundation/Dev Blog with guest posts.

Also, I am confident that anybody who will eventually have to use this will be capable enough to work with either solution.

In the meantime, I suggest we redirect the discussion to productive input as to what kind of content would be most appreciated.

Thank you all so much for your help. I would be lost in wordpress-land without you.

[markknol]

I like wordpress tbh. It has all features I need and can easily be extended, its pretty good and has great userfriendly admin. /me hides in the bushes 😅

About the content, I just randomly dump my thoughts:
It would be great to have some items that are recurring, like links to the roundup, monthly highlights/thoughts from the compiler team (those tiny bits of simn are already very interesting), now and then updates from the website team. Also it would be nice to highlight real products/games created with Haxe. For example that Tivo article is great and I think there are more companies willing to write/showcase "their" tech to the world. Also we could blog about major updates on libraries like openfl/nme/heaps/flambe/haxeflixel etc etc. the blog is also way of communicating new stuff, like when the roadmap is updated, when wwx2016 is announced, when the shop.haxe.org is lauched, when a new Haxe version is (almost) launched, to highlight specific features of a release, when we do another crowdfunding project to reach x, when any haxe IDE has an major update, when we reached cross-universe state, to communicate what the answer is to short-lambdas, when we attempt to adopt another language, when we call out all developers to star us on github, when we got massive attention from new developers who want to be cross-universe too, when we updated the API docs, when there is an interesting piece of try.haxe, why x can be solved with macros and how etc etc..

there is so much to tell, I think the blog should be the way to communicate the Haxe-world to the world. I think we can do this right.

[delahee]

2cent ... Whatever technical solution, it's the owner affinity to the tools that should prime, especially since all great contents are now inter-exchangeable. voting for this is not very desirable :)

[polarathene]

While blog posts with all mentioned content is neat, sometimes there is interesting/relevant info in past blog posts, perhaps a google search landed on a few blog posts back and the area of interest to the user is discussed in previous articles. Tagging becomes useful here, along with related posts. Please consider discoverability, I've personally benefited from this type of feature many times in the past.

A similar type of feature that is more granular than blog posts as a whole would also be neat to have in the future, plenty of content buried in past haxe.io/roundup posts, tutorials/articles or libs that'd be a great resource. This would take a bit of work to get any past content in and organized along with things like ranking elements for display(quite a few metrics to take into account).

[lucamezzalira]

Can't we use medium to have the possibilities to reach more people and maybe have a simple page in the website where we collect all the article on medium?

[Merelleya]

I actually would prefer to have the posts themselves on the haxe.org site so as to have editorial content that is being updated regularly.

Since I have never worked with Medium I don't know what impact it has on discoverability, though. Any opinions?

[lucamezzalira]

The plus on Medium is only the fact you can reach new users because anybody could write in that platform and all the articles are shared across the Medium network.
Recently I saw a lot of bloggers moving from wordpress to Medium and I saw @ncannasse is using it too.

Another interesting metrics that could be more a "marketing move" could be write also on linkedin, recently I published the same article on Medium, Linkedin and my personal blog, the results?
Linkedin is the most viewed for now

I don't know if this experience could help but I hope so

[Merelleya]

So we should keep this in mind and maybe:

• have our blog
• occasionally post on medium and/or linked in
• Have a page where we collect articles (not just our own but other's, too)

@lucamezzalira how do you deal with duplicate content in this context? (I assume if you post the same post on several platforms it might get identified as duplicate?)

[lucamezzalira]

What I did last weekend was just a manual copy and paste in different platforms, they didn't complain 👯
Probably there are better way to spread the post in different platforms, mine was mainly a test to understand which platform reached more people

[polarathene]

You might get ranked lower in google searches if crossposting to multiple blogging platforms due to duplicate content, if anyone has SEO knowledge that'd be useful to verify? Crossposting would likely still improve discoverability and these platforms themselves rank pretty well, just back link to the original haxe blog. I guess you could automate submission to the platforms, social media accounts sharing title+link, reddit submission etc.

I don't know if there is much more benefit doing exclusive posts on the other platforms, community has been trying this already :)

[lucamezzalira]

good to know, I'm definitely not an expert on SEO stuff!
Mine was mainly a test to understand which platform was more interested to the contents I usually write.
that's it

[Merelleya]

That's why I asked how you handled duplicates. Duplicate content, especially on different sites, is an absolute no-go, SEO-wise. Since the other platforms have a better ranking, you would actually hurt the ranking of your own site. It is one of the reasons why paid and free press releases have no SEO value whatsoever^^.

It is ok to cross-reference, though as long a s the content is unique. (Write about the same topic from a different angle or for a different audience and then referencing the initial post).

[polarathene]

How badly would it affect SEO though really? If you publish via the Haxe blog along with social media promotion and reddit, then after an amount of time eg 1-3 days cross-post to popular blogging platforms that back link to the original article at the start, would the added exposure not be more beneficial? Due to the back linking and giving google time to index the original article, I'm not sure if your SEO ranking would be impacted that negatively, it might even recognize that Haxe is the source article and therefore duplicate articles should hold less weight(so no penalty). I'm no SEO expert so I could be wrong. Depending on distribution channels and blog titles the additional exposure to those popular communities may be more valuable than search results for discoverability. They'd each link back to the original blog and be promoting Haxe, if the SEO ranking was affected for the blog would that impact on the Haxe domain?(assuming that's where the blog is hosted)

Interested readers will either go via the link or google 'Haxe'. 'Haxe JS', 'Haxe mobile', 'Haxe games', 'OpenFL' etc. In terms of duplicated content and relevancy, the Haxe domain or other community websites would likely outrank the blogging platforms for those searches?

[Merelleya]

There is a lot of "try this and maybe..." in SEO. Duplicate content is not one of them. It is very, very bad and thus to be avoided. Apart from the obvious communication benefits, there is another reason why I am insisting the blog be part of the website.

Seeing as it is editorial content (whereas the rest is mostly static), it will do a lot to strengthen the sites position and help get ranked for other keywords than just "haxe". If we have duplicate content, it will not only not achieve this goal, it will also hurt the ranking as it currently is. So yes, it would impact the whole site. If we were to have it on a separate site and then start duplicating the content, the separate site would not gain traction in rankings at all.

Artificial back-links are another issue. While you can do a lot to tempt people into linking to your site, most links that you create yourself (by re-posting and linking your content on forums, other blogs, reddit, etc.) will be no-follow links and hence not very valuable.

Additionally, most good News Sites can outrank the "source" website simply by having more editorial content, a longer standing and so on. so it might well be that the results on those pages come to outrank Haxe's own website, which is also not the point.

Also, one does not have to re-post whole articles to spread a particular piece of content. There are a million other ways to do that and if one really does want to branch into a new platform, like, lets say, LinkedIn, it would be much nicer to actually write something for that platform.

You can see a good example of this if you look up one of @larsiusprime s articles that he also posted on gamasutra. The gamasutra entries are ranked very well, the entry on his personal blog often does not even appear. While this is ok if you are looking for exposure, this is definitely not what I Want to achieve for the website.

Google is investing a lot of thinking in preventing people on the web from artificially pushing SERPs and we are at a point where it works quite well which is why good content is so important. It is the best thing you can do for any site.

Anyway, this topic is really not aimed at discussing the Dos and Don'ts of SEO in itself. The blog is to be part of the website and it is to benefit the website. I will not be able to consider any solution that subverts this goal (even partly). Of course, I will be more than happy to help, if you have any questions. Just send me an e-mail or drop by the IRC.

[Simn]

See HaxeFoundation/haxe.org#159