Topics

Anahita Project

Anahita Project's Topics

Andrea Torre

Andrea Torre

September 02 2014

Focusing on back-end. Front-end in AngularJS.

Hi all,

this is just a proposal :)

1. The idea is to focus only on the #backend, ignoring the front-end in the coming months to make available powerful, complete and well documented #RESTful / #JSON #APIs to the dev community as soon as possible.

2. In parallel, the idea is to start a new project on GitHub for the front-end, likely using #AngularJShttp://www.angularjs.org and Bootstrap. This can be done only if the back-end APIs are mature and well documented. See point 1.

Why:

3 points:

a. No matter how much it will be well done... anyone who wants to create a product including Anahita in his technology stack will create its own front-end, likely from scratch or, if available, from general-purpose front-end frameworks (AngularJS, Bootstrap, etc.). It's really hard to think of an unopinionated front-end "to fit all".

b. Focusing only on the backend and the RESTFUL / JSON APIs drastically speeds up the project and will also increase the popularity among developers. More quality, more speed.

c. The MEAN stack - http://mean.io idea is becoming increasingly popular in the PHP world as well, using Laravel instead of ExpressJS/NodeJS - http://laravel.com/https://github.com/laravel/laravel

  • 18 Comments
  • Last Comment by Andrea Torre
  • Rastin Mehr liked this
Rastin Mehr
Rastin Mehr
September 02 2014 Permalink
I like the way you think. In our new direction we are focusing on building APIs first and then put a minimalist UI on top that only uses the most essential API calls, but more complex projects either build their own front or build native apps that use Anahita as a cloud back-end that gets smarter as the service gets used over time.
Unknown Person liked this
Andrea Torre
Andrea Torre
September 02 2014 Permalink
Hi @Rastin, Anahita as a cloud back-end is exactly what I mean.

I like the new direction, how-to's, examples and APIs descriptions are necessary as well.
Rastin Mehr
Rastin Mehr
September 02 2014 Permalink
We welcome all the help you and other people in the tribe can provide.
Unknown Person liked this
Nick Swinford
Nick Swinford
September 02 2014 Permalink
I've been using #Emberjs for a few projects lately and really enjoying it, but I worry about implementing a full MVC Javascript framework for the front end. There are alot of unsolved problems there currently, #SEO for starters. Plus, it would add an extra laryer of difficult in new developers getting up to speed with #Anahita.  I think we should stick with a #php frontend, but I've been thinking more and more about possible using #backbone to handle some of the more complex javascript that #Anahita has, not to mention better code organization.  That's why I recently made a post about using #handlebars in the templates.
2 people liked this
Andrea Torre
Andrea Torre
September 02 2014 Permalink
@Rastin I'd love to help more. It would be really helpful for you to supply the relevant #documentation.
Providing documentation to increase the active developers is now one of your priorities?


NicholasJohn16 yes, #SEO and client-side #JavaScript is a very interesting topic but it is not an unsolved problem. Anyway this probably deserves a separate thread.

Personally, I do not know many startups founded in the last 2 years using PHP for the front-end. Obviously I do not pretend to know all the startups out there :) anyway, I think this is an interesting starting point.
Also, I think #AngularJS would be a better choice than #Backbone http://www.quora.com/How-do-Angular-js-and-Backbone-js-compare
Rastin Mehr
Rastin Mehr
September 02 2014 Permalink
We don't have a documentation to supply. We simply read the code and until now it's been a challenge maintaining docs because Anahita's architecture has been changing drastically from release to release. Also time is a major factor. If we write documentation then we'll have less time to do development. The #DocCamp initiation in my opinion added a lot of new documents to the Anahita. Perhaps we need to organize more documentation events where everyone can contribute.
Rastin Mehr
Rastin Mehr
September 03 2014 Permalink
Unknown Person liked this
Andrea Torre
Andrea Torre
September 03 2014 Permalink
@Rastin, by not writing #documentation for the core development stage only saves time in theory.

Also, in my experience, this only works when the team is made up of 1 or 2 ninja developers who are not going to grow the number of the team.

In practice, however, the real scenario is as follows: 

by not writing documentation you keep the "bus factor" too low - http://en.wikipedia.org/wiki/Bus_factor preventing other developers to join the project and accelerate the development. 

The number of developers remains the same for a long, long time while the evolution of technology travels at the speed of light.

For example, how many key developers were involved in this project in 2008? If the memory serves me right: you and @asanieyan — how many today? 

Sorry if I sound like a broken record but I love this project, I was among the first partners to join 5 years ago (July 2009) and now, IMHO, I think it may be appropriate a change: documentation first.

The #DocCamp is a nice idea but is not the answer in this case.

The DocCamp topics are more about DevOps and informative articles — while, I'm talking about that kind of constantly updated documentation that can attract other developers and maintain the high quality of the code.

In this phase, this type of documentation should be written by founders/key devs.

AngularJS vs. JQuery:

Intersting link. As stated in the article, I don't think they can compare. #AngularJS vs. #Backbone.js would be a better comparison.

#JQuery only focus on DOM elements and no data CRUD.

#AngularJS is a REST-friendly web application framework with MVW, MVVM, MVC capability. Declarative templates with data-binding and dependency injection.

CodeSchool has just released a free course about it https://www.codeschool.com/courses/shaping-up-with-angular-js

Another great AngularJS resource is https://egghead.io/technologies/angularjs

Here are #Bootstrap components written in pure AngularJS http://angular-ui.github.io/bootstrap/

Hope this helps.
Nick Swinford
Nick Swinford
September 03 2014 Permalink
People debate #Angularjs vs #Backbone endlessly. I personally prefer #Emberjs. Its a much more extensive option with a great data layer. (Here's a great article comparing the two.) #AngularJS just looks ugly to me. The non-standard html tags and attribute just look kinda wrong.

#Backbone on the other hand is a nice light, minimalistic framework that we can use to replace #mootools and add in functionality as it suits us. It can handle the heavy stuff without taking over stuff like routing that we don't need it to.

@Rastin, I have to agree with @Andreatorre. The Anahita core code is daunting to a new comer, like me. I've tried several times to make headway into reading and understanding the code only to hit a roadblock and get frustrated.  If we're ever going to increase the #Anahita user base, we need to lessen the learning curve.
Unknown Person liked this
Andrea Torre
Andrea Torre
September 03 2014 Permalink
@NicholasJohn16, thank you.

This is another interesting debate about #AngularJS vs #EmberJS raised by the Ghost Team on GitHub https://github.com/TryGhost/Ghost/issues/2144

In the end... they choose EmberJS because: "it is strongly opinionated".

IMHO, EmberJS+Handlebars or AngularJS is a nice debate to have after the step 1 described in the first post of this thread.
Rastin Mehr liked this
Rastin Mehr
Rastin Mehr
September 03 2014 Permalink
I fully agree that #documentation will make it easier to learn the technology and ideally the documentation would be written by the founder and creator of the technology. Unfortunately I cannot afford to create the time and write any sort of documentations for the next 8 weeks at least. We need the new codebase for upcoming projects and our clients are waiting. I can't put our developers to contribute directly to Anahita, because they are getting paid to work on Client projects. What I can do is to curate code and reimplement them in the main branch in a way that is reusable for everybody. It would have been nice if we were financially backed by large companies like Google, but that isn't the case. Right now Anahita is supported by my company and the contributions of the Anahita tribes.

In the mean time you can lend me a hand by reading code and writing docs. You have all the tools you need and I am avaiable 2-3 days a week when I do the weekly #Anahita #Hackathon to answer your questions and go over your writings.

Documentation will never replace what code reading does. If you want to get down to more hardcore devleopment, you need to understand what the code does and all it's strengths and weeknesses. I spend half of my time reading the code that Ash, Johan, and the rest of Nooku team have written. I spend time reading the code I have written myself months ago just to recall what I've been trying to accomplish at the time. This is an inherit part of the process. 

Question: did any of you edit and save your comments multiple times? I am trying to sort out a bug.
Unknown Person liked this
Rastin Mehr
Rastin Mehr
September 03 2014 Permalink
Also thank you @andreatorre and @NicholasJohn16 for the discussions on the js framework and shared resources. This type of conversations save us plenty of research time and it is a valuable contribution.
Unknown Person liked this
Andrea Torre
Andrea Torre
September 05 2014 Permalink
@rastin 8 weeks is not forever :) I'm happy to help and I think that collaborators will increase if there is determination and a clear strategy (whatever it is) to increase the "#busFactor" in the coming months.

About #documentation: If I may paraphrase you on this: "Documentation will never replace what code reading does... provided that you first read the documentation". 
Quoting @johanjanssens: "Developers expect stability, documentation and support."

Bugs: Yes, I edited the text a few times. I recently switched from the Italian keyboard to a US one :)
Rastin Mehr
Rastin Mehr
September 05 2014 Permalink
Here is the plan. We want to have the Anahita 4.0 Birth release ready in about 4 to 6 weeks. Then we can organize another DocCamp so we can continue with writing documentation. I will be joining you guys to write some pages too. Before that date we can organize weekly hangouts with a selected number of you guys so you can ask me questions or I can teach you some of the core framework aspects of Anahita. That way I can pass on the knowledge to you and also understand what topics need to be written down as documentation.

I need time to be able to write documentation and that will only be possible if you guys pick up some of the development and documentation work, otherwise it won't be possible for me to write code and documentation in the same time. I will not stop the development for the sake of documentation because we do need the upcoming codebase.

Also the documentation ages very quickly and needs to be maintained. Keeping the docs update is what you guys need to pick up on which means you need to constantly read code, ask questions, and write down the answers in an organized fashion for everyone to benefit from.
3 people liked this
Johan Janssens
Johan Janssens
September 05 2014 Permalink
Andrea : About documentation. I still 100% disagree with you and 100% agree with Rastin. Code comes first, documentation comes later.

When I talk about 'documentation' I mean code documentation in the form of proper docblocks and API docs as we are now working on for #nooku

If code is written properly, using programming patterns and with descriptive docblocks it's becomes self-explaning. Modern IDE's allows you to easily discover the code, either because they understand the relations between classes and object or because they allow you to step through the code with a step through debugger.

Documentation outside of the code is useful but not mandatory. I can be used to convey principles and choices made. It can help to explain 'why' and 'what', not 'how'. This kind of documentation is only something you can write when you entering a stability phase, not before.  Our Nooku guides are just that, they will answer 'why' and 'what'. They won't teach you how. 

If after reading the code, API and guides (if available) you still cannot get started, then you need to up your skill level, or find another tool. It's that simple really.

Why ? Because we are not building products, we are sharing code. It's a gift economy, not a cacapitalistic economy. Don't expect us to give, if you are not able to give back. That's not how it works. 

Finaly, if you consider Lavarel to be the next thing for PHP, Anahita is definitly not for you. That's like trying to compete in an F1 race with a threewheeler.
2 people liked this
Andrea Torre
Andrea Torre
September 06 2014 Permalink
@johanjanssens thank you for your direct contribution.

I partially disagree with you.

"Partially" — because I have learned to avoid absolute expressions like "100%", they do not help me to stay open-minded.

The spirit of my debate is to question what I consider not that clear in order to be constructive (and yes, even what is now considered obvious by everyone).

About Laravel: I never said #Laravel is the next thing for PHP.

I simply said that mean.io (and similar) represents a kind of stack that is becoming popular even among PHP developers — but with Laravel instead of ExpressJS.

Laravel, the #opensource three-wheeler, has got almost 4.000 forks on GitHub and my observation was just about the concept of popularity and not about "Nooku vs. Laravel" (I've never even written the word #Nooku in this thread; for some reason I think that your reaction was slightly emotional).

About documentation: "Documentation outside of the code is not mandatory" sounds like a statement. 

I prefer to merely observe the reality as it is: open source projects are only as strong as communities behind them. They need lively communities to succeed, which often are encouraged by a proper documentation and an increasing "bus factor".

In other words, I'm not sure that properly written code + modern IDE is enought to grow vibrant and large communities of developers.

About "The Cathedral and the Bazaar": I'll quote 3 points from the essay (among the 19 lessons learned by Eric S. Raymond):


Point 6: "Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."Point 7: "Release early. Release often. And listen to your customers."Point 8: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."

I hope some of what I wrote makes sense.

@Rastin thank you for proposing a plan.

Andrea
Johan Janssens
Johan Janssens
September 06 2014 Permalink
About emotions : Of course my reaction is emotional. I'm motivated by passion and purpose. 

We are open source developers, not horses. We are not driven by maximizing profit, but maximzing purpose. To do so we leave our suits at the door and replace them with a great dose of passion. 

About Lavarel : I will quote Tom Dale here :  "If you use a PHP framework based on popularity you deserve what you get."

Open source is not a popularity contest.  It's about the right tool for the right job and 99% of the time the right tool depends on the skillset of the developer. There simply are more less skilled developers then skilled ones. Easy math.

About success : I again disagree with you that open source projects are only as strong as the communities behind it and need them to succeed. 

The opposite is actually true. The more people work on code the lower the quality of that code. Or the bigger the community the less success.

Open source success is not measure in use. The success simply comes from the act of making the code available under an OS license combined with the commitment of the developer to maintain that code, either alone or through contributions from others.

About Catedral and Bazaar : 

- A co-developer is someone who can understand the code without the need for documentation or additional guidance. Someone who needs additional guidance will only be able to 'use' not contribute or improve.

-  Customers as in co-developers, people who can 'give' time and code back to you. Not customers in the traditional sense of the word. They cannot give, they can only pay you.

- See above, this is not true.

Rastin is a great example of a co-developer. He understands Nooku without ever having read ane line of documentation. He understood the code, scratch his own itch and build Anahita. By doing so he is contributing the success of the whole. I can in turn re-use his code and build further upon it. 

To be frank, proposals/ideas are a waste of time. We have saved the world 3 times over already with those. Scratch you own itch, make it happen, then talk about it. 

Johan
Rastin Mehr liked this
Andrea Torre
Andrea Torre
September 06 2014 Permalink
Johan I'm really sorry you consider this proposal/thread a waste of time.

I think this conversation is about ideas, #knowledgeSharing and passion, which combined with #execution can sometimes result in significant outcome.

About Laravel:  I'm surprised that you keep misrepresenting my words. It was not a judgment on the quality of #Larvel — it was a observation about the mean.io stack and the popularity of Laravel in that specific context.

About success: Anahita is an amazing project and I agree with you: @Rastin is a great example of a co-developer.

5 years ago the factor that represents the measurement of the concentration of information in key members of #Anahita was = 2.

Today this factor is = 1 ( @asanieyan left the project ).

If it became zero for any reason, the success of this specific project might be compromised. Easy math. Code alone is not enough.

Also, this is a deterrent for early adoption and both #Nooku and Anahita have come to light by proposing a program for early adopters a few years ago.

I still believe that an #openSource project depends on the community's size, capacity, and needs. This is just my opinion, which you are of course free to disregard completely.

Happy Sunday,

Andrea

Powered by Anahita