For the first bit of the video we’re planning Novae’s parsing/validation system; At 35:28 min in, Qriz returns from yesterday with updates on his card game work (yesterday, we helped make a basic card game template in JS, he did UI work over-night and we help him integrate the JS in to his UI elements)
Schedule (Pacific time zone, GMT-7, PST/PDT)
Tuesday, Wednesday, Thursday
_by_ 1:30pm until 4:30pm (I will aim to be up by noon in the future)
Monday 6pm to 8pm PST/PDT
Saturday 12:30 noon to 4:30pm
#What is Novae?
Novae doesn’t exist yet – this stream is ‘the making of’ Novae. I hope to:
(1) attract other like-minded developers to collaborate on this project with me (bonus points if you want to stream your progress with me, or follow my stream to collaborate together).
(2) help new and intermediate developers learn from my experience
(3) showcase the development methodologies I am including in Novae, to hopefully attract a following for Novae itself
#Who am I?
I’m a senior PHP developer who recently exited the business I founded, a highly successful VOIP-enabled CRM. At my time at that company, we developed a framework that had a lot of elements that other frameworks don’t have. Unfortunately, it was also closed source, but fortunately, there were many differences between it, and how I would design a framework today.
#What makes Novae special?
Right now, nothing – it doesn’t exist! Hopefully that will change very soon. Development began Oct 2nd.
In the future? Novae will speed up development of new PHP *APPS* (web apps, server side apps and scripts).
#What are some of the design decisions other frameworks have made that you don’t agree with?
To start with, the ORM and Database abstraction.
Designing the constraints of properties in code comments causes additional work for the developer, and forces an abstract language to have to be learned.
## There’s a large general problem that any developer of a framework (or any site with-out a framework:
Code comments, Code/class descriptions, database design, and documentation all reflect the same thought that the developer is trying to get out. The developer (or team) does all of this.
Some ORM frameworks solve this with code comments that represent the property relationships between classes: that is arbitrary, and forces learning of an additional modelling language on top of the ones we’re already using. Further, if this automates code, then it’s effectively turning PHP in to a compiled or built language.
Others solve this with Docblock, which only serves to automate the documentation (fortunately also linking it to the version/build/release).
I’m sure there’s other ways it’s been “solved” — send me a message and let me know some of the ones you’ve seen.
In the meantime, my focus is instead on having the code you write, automatically produce effective documentation and database relationships. I want developers to write code once and have that automate, with-out compiling or preprocessing your PHP files, effective documentation, database models, and both REST and SOAP API endpoint descriptions.
## SQL abstraction is similarly abstract
I believe the bulk of SQL code should be written in SQL, and that should only change when there’s a *performance* reason not to. By performance reason, I mean that the code should be more simple because SQL abstraction functionality was used.
Developers should be assisted in writing good SQL on top of a strong foundation of SQL. Security should not be a concern for the framework, at least not at the expense of added complexity for a good developer.
If the framework can cause the developer to write less, and gain security, then it should do so. If the framework forces developers to write (or think) more to enforce security (or abstraction), that isn’t good in my view.