creynders
commented
10 years ago The following are my opinions, not an "official" Geppetto vision or anything. @geekdave 's the Geppetto sensei, who sets out the path. I.e. I'm only speaking on my behalf.
a willingness to hear me out when I do start to use this codebase
That is a given. When something makes sense, it makes sense. This is OSS, the whole idea is to get the best possible code collaboratively.
I would be happy to give a good shot at sourcing a board of logo ideas that you could choose from.
Feel free to do so, but don't expect anything in return. Personally I'd feel a bit awkward if you do ask people to invest their time in coming up with a logo for a project they don't have a connection to themselves. To me the logo's a must-have only in the sense that we need a visual denominator, but the future of Geppetto does not depend on it.
to ditch the AMD model and keep it simple with browserify.
We won't be ditching the AMD model any time soon. We just made sure Geppetto's compatible with a CommonJS model as well. And, given the state of affairs; RequireJS is way too popular and used in too many projects to cut those people off (or deny ourselves the userbase).
this keeps up with what makes sense for the browser and not Node.js
Geppetto's a front-end lib foremost. I myself have very little experience with Backbone on the back-end and TBH don't see the point, so my focus for Geppetto will always be on the front-end. Except when maybe some day it does make sense to focus on the back-end as well.
I just think it makes sense to break ideas up and talk about them more as their own thing.
I agree. When it's appropriate. ATM I see no use/necessity to start splitting Geppetto up. But as I mentioned in the other thread I do want to think about extensibility and probably that will result in a number of extra modules.
You just gotta take my word for it that I am not just some bullshit troll.
Word taken. Without hesitation :smile:
howardroark
geekdave
We were talking about this in #69 (hehe), but I really got to thinking about it. I work in advertising and do have a lot of talented art directors at arms reach who I could ask a favour of. Yay for bartering!
I would be happy to give a good shot at sourcing a board of logo ideas that you could choose from. If the idea of a falling star is something that you are interested in I think it would be really easy for someone with talent to work with. Keep it vector for reusability and think about from the perspective of Gravatar use cases.
All I ask in return is for a willingness to hear me out when I do start to use this codebase. I love that you now plan to ditch the AMD model and keep it simple with browserify. Awesome start! I would just want to have the option of influencing things through real rational argument from time to time; on the basis of economics. If you end up being too busy at a certain time, no biggie... I am no big hurry!
The projects I plan to get working on will involve having an entirely open-source codebase that follows the UNIX philosophy as best as it can. This really just means breaking it all up into tiny little projects and giving them all a smart API and philosophy for use. The main focus will be on documentation and approachability for each piece. The basic idea is that if each piece of the puzzle properly corners a pattern that meets an economic need it will run at a low cost of labour. It also ensures that your labour is up on all of the latest trends and has a good vision for technology.
I work in advertising and really enjoy working on operational problems, be it business or technology. I plan to start working with advertising companies to get their teams on board with with the latest open-source and development trends. The ideas focus around delivering your front-end over CDN with things like Jekyll or assemble.io. It also revolves around building services in Python to solve your problems. Harness all the projects out there to build smart APIs that focus on delivering JSON to the browser. In terms of DevOps it is all about using Node.js... get everyone on the Linux command line at the very least to operate version control and automation tasks. This will involve the use of Vagrant, SaltStack and Docker. It also offers the opportunity to make API services more deployable and reusable as well. The point is that you get far less downtime in Marketing if the UI is just static files served over a CDN. My challenge is to convince them to care, but I enjoy that :)
It is awesome that you made an organization for this, because it will allow you to break things up where it may make sense. Use the idea of Geppetto as the basic philosophy for this project rather than looking at it as one big file. Keep it so that you can really make strong use of CommonJS. I have no idea what they could really be broken up into. That is where you come in! I just think it makes sense to break ideas up and talk about them more as their own thing. It creates more of a chance that someone else will end up using a part of it and eventually contribute back. Having it all as one file is just an Old School thing, web 2.0 let's say. I just feel that you have to employ the UNIX philosophy to build CommonJS well. Maybe you give everything that names of puppet making tools, who knows! It's up to you... the bosses!
The main thing to keep in mind is that I will be using Python for all web services and will always want to ensure that this keeps up with what makes sense for the browser and not Node.js. I am totally down to debate about it, but it has to be about economics. I already think that duo and normalize are better theoretical ideas than browserify. I would never want to have to call my JS project something else just because it was taken on NPM. That is just plain terrible. I want to give projects names that have meaning so that people can better understand them.
How does that sound? Got a deal? You just gotta take my word for it that I am not just some bullshit troll. Haha.