livfoss wrote:What I think is wanted is to attract not only people like me (lots of development experience, but not quite enough time and energy to enter completely new fields) and also people who have responded to LC's "Everyone Can Create Apps” proposition but then tripped up over deployment.
What do others think?
Have you seen Scott McDonald's LiveCode Lab? It's pretty cool, a sort of platform-as-a-service for LiveCode Server:
http://thelivecodelab.com/
I was prompted to take a look at it again in response to your post, and it seems we have a multi-tiered pathway for folks wanting to learn server stuff with LiveCode:
1. In many ways
The LiveCode Lab makes great starting point for using LC Server, taking away all the complexities of server administration and letting folks just focus on scripting LC.
2. Once they get the hand of things there, using a
shared hosting service where LiveCode Server is pre-installed may be a good move. At the moment there are two: on-rev.com and hostm.com. Hopefully there will be others down the road.
3. Those needing a wide range of hosting options can move on to nearly
any shared hosting service, and over time perhaps some of us can make one-step installers for them.
4. And more advanced users can explore custom socket servers and other microservices on low-cost
VPSes.
There are several challenges with web development:
- Multi-lingual: in the browser objects are HTML with appearances defined by CSS and interactivity provided by JavaScript. No matter what's used on the server, what's delivered to the end-user in a browser is HTML/CSS/JavaScript, so familiarity with those is essential. And they're very different from LiveCode.
- Security: distributed systems like web servers are under constant attack (well, so is the computer you're reading this on now, but hopefully you're using an OS with zero open ports by default), so anyone responsible for deploying web apps is responsible for making sure they're server isn't hacked, in much the same way we need to keep our desktop from being compromised so we don't ship infected apps. But a local computer can be turned off, while a web server is (hopefully) available 24/7, meaning it's under attack 24/7. At a minimum a web developer needs to become comfortable searching through log files for potential or actual risks.
- bash: Most servers have no GUI; on a server a GUI just wastes RAM and CPU resources since there's no one physically at the machine looking at it. We interact with servers via Terminal, and use bash to navigate, launch processes, move files, set permissions, etc. It's possible to use FTP alone for very simple things, but sooner or later you'll need to stop a runaway script or do something else that'll require bash. It's not that hard to learn enough bash to do most useful things (probably just a dozen or so commands), but like anything else it takes time to become familiar with it, and to set up shared SSH keys for logging in securely and efficiently.
Once someone has acquired the knowledge to handle those challenges well, even the existing LiveCode Server tutorials will be relatively easy. While more tutorials can always be helpful, the scope of knowledge needed for web development lies far beyond anything specific to LiveCode.
So the 4-point outlined above is one way to mitigate these learning requirements, by choosing environments that have a balance of flexibility and prefab support suited to each of those experience levels.
Not all of them will be for everyone, and that's very much the point: one can dive in with any of them according to their own interest and experience levels, and can always move on to greater challenges once they feel the need to do so.
