It says "No setup, No configuration". But what if I want to configure stuff? For instance, there's a lot of things going on in settings.py.. to name a few: - setting up the DB - email config - celery (tasks and stuff) - Caching
How much control do I have on the "cloud"? I.e. if I want to create a folder to put the files uploaded by users? If I want to run background tasks?
Also: How does one switch from dev to production? Does Kite plan to offer a robust solution for production down the road? I'm not overly concerned because since I have a local folder, I can easily deploy it to any vps.
I have dozen of django projects and I'd gladly give it a fair try, let me know: phzbox at gmail.
We wanted zero setup for devs who may just want to get something up and running right away. The video shows the basics, and we definitely realize there is much more to building a web app than that.
We want to make configuring your app and using common services easy without Kite getting in the way. That’s our mission. Although we showed direct shell access to your app in the video, our end goal is to give developers a machine they can call home as their development environment - root access and all.
For databases, we’re making it a simple click to bind a database to your app. Similar to Heroku, we plan to expose different options as a service and they will be connected to your app through the dj_database_url python module (for Django). For beginners, we’ll try to edit your settings to help make this seamless (your settings.py files in this case).
For other services such as email, task queues like Celery, memcached, etc. we plan on taking a similar approach - offer it as a service on a separate machine that can be easily added to your app, or alternatively just install it in your environment if its something very lightweight or serverless (like sqlite).
Like other hosting services we’ll provide storage for things like storing user media, static files.
We’re really aiming to start with development, since there’s this large gap between development and prod that creates serious time-wasting problems that each member of our team has felt. Companies like Heroku are solving the production problem very well, but developers are still left to setup their own environment and deal with problems leading up to prod.
That being said, we see the serious benefit in using the same stack for development & production, and, like others have mentioned, testing, staging, CI. It’s definitely on our mind, and we’d love to see this kind of fragmentation disappear.
Great to see that you’re interested, and we’ll definitely be following up with you soon.
I think the only benefit to Kite is if you want your development application to be running from a public address for a long time.
The PageKite approach allows you to have whatever web environment you want and to bring it up/down at will. I have used PageKite for over a year and it has worked very well. It also seems safer, since I wouldn't want to deploy my development changes to a public web site with some unintended security flaw.
While PageKite definitely offers a great way to expose your local web app to others, we want to get rid of the local setup process altogether, so developers can just spin up an environment using our service and start working from their favorite machine.
Our initial target is newer web developers who may find the setup process daunting, or developers who may manage several projects but don’t want to worry about about the details behind setting up different web frameworks and adding new services. As many can attest, setting up Rails isn’t exactly easy, and it can be even worse if you’re not familiar with the command line, or don’t have xcode installed.
We're definitely working on ways to allow developers to work privately and avoid publishing by default.
So in the case of git, you can keep using VCS just like before - place your local files in a repo and use the Github app / command line. Our goal is for you to continue to use the workflow you're used to.
Overall its a great concept and something I think you'll see done by companies like Heroku as a form of lock-in as teams grow and never really learn how to virtualize their workflow. If you can get on the front of that movement it will be interesting to see where this project goes.
Good Luck!
Some friendly advice: From the homepage, it seems that the focus is on apps in development. This is well and good, but I think your marketing should also mention that you're great for hosting apps in production too. And if you're not great at that, yet, you should try to improve -- for the good and simple reason that, at the end of the day, it's products, not prototypes, that generate revenue for your developer-customers and allow them to pay you.
When developing something serious, you typically want to match the stack you will be deploying on. So far, the two easiest (not necessarily wisest) options have been Google App Engine and Heroku, with latter being my choice of late due it running on AWS and "closeness" to S3 and DynamoDB.
Our video is indeed starting a django project for you - we take a step further and let you do that in a click without having to set up a virtualenv, and it's all hosted. This is the basics, but the idea is to move your development onto a hosted server that is the same or much closer to your prod environment.
Ideally, this hosted environment can offer you much more than what you get by installing a different version of everything you’ll be using in production onto your laptop.
I definitely see the benefit for those not utilizing such practice already.
I'd love to use this to develop my Rails applications. I would be using Kite as a 100% staging server to test things out before pushing to production. I don't have to worry about setting up different RVM gemsets for different apps.
A solution like this is the perfect environment for someone who is trying to learn to program.
I did notice fan noise increasing steadily in the background. Hopefully those issues will be sorted out before release or are caused by the screen casting software. At the very least, its presence indicates an honest demonstration.
Your clean page, and the design and colors of your icon led me to think at first that this was a google project.
Compare your logo to that of google play's logo.
If multiple developers can modify files at the same time, how do you handle merge conflicts when syncing?
At this point we're not focusing on collaboration between developers. There are incredible companies like GitHub whose core mission is to make code collaboration an amazing experience, and we really want to help developers leverage this while not worrying about environment, config & setup issues.
Thanks for the comment!
