Just thinking about the issues of generating exposure for the Lucee platform and possibly attracting new devs. There should be a concerted effort to cross-link - people/orgs linking to the Lucee homepage, docs, etc. Links from Lucee wiki, etc. to blog posts with relevant information, etc. Cross-linking will drive search rankings and help generate traffic.
That’s a good start but not necessarily enough on its own, but we could all help generate more awareness about Lucee through content generation that breaks out from just Lucee. I have been writing blog posts lately about Lucee and various other things. One of them in particular, about my shell script to stop and start Lucee and Nginx:
http://www.bonnydoonmedia.com/index.cfm/blog/shell-script-to-start-and-stop-lucee-and-nginx/ http://www.bonnydoonmedia.com/index.cfm/blog/shell-script-to-start-and-stop-lucee-and-nginx/
has generated over 50,000 views since I originally posted it in late February, and it is still generating a lot of traffic everyday. I figure some of that traffic is related to people looking for Nginx scripts, but I don’t know how much is Nginx-related and how much is Lucee-related. I am going to continue blogging in that vein - mixing subject matter like Nginx and Lucee, jQuery on the client with Lucee on the server, etc.
As for why Lucee, that’s my entire point about pushing performance. A new Lucee dialect is a positive move. Add better tooling - IDE, text editor plugins ( good to see that in motion already ), and you have a good case for Lucee, but not quite a compelling case. Rev up performance and I believe you have a compelling case for Lucee over other platforms. Components of success:
- Lucee IDE and plugins for text editors
- Engine re-write targeted at generating optimized Java code for maximum performance
- A successful web site using Lucee as a showcase
What about a project to generate an optimized Java version of Coldbox or FW/1? That would provide an immediate boost to sites running those frameworks without trying to optimize any and all CFML code. Is that still too big a scope?> On Jun 11, 2015, at 9:44 AM, Andrew Penhorwood <@Andrew_Penhorwood> wrote:
Adam Cameron wrote this blog ( Adam Cameron's Dev Blog: CFML: does it have a USP any more? ) which was a spin-off of a thread on this list.
My take on CF, the language. First lets get out of the way programming experience. I started programming in 1980 long before CF or the web. I have used around 25 computer language to include Assembler, Java and Visual Basic. So learning something new is not an issue. I can do that in about a month. But I have used CF day in and day out for the last 15 years. The main reason is bang for your buck. Getting stuff done in CF is easy. If I need to talk to the database I simply use cfquery (tag or script). Nothing gets in my way since I can stuff any valid SQL between my tags. Need to talk to a 3rd party on the web, makes that easy. Need to keep my variable space clean then use cffunction. Have you ever tried to do some of these things with other languages? Let’s just say not easy. Maybe that has changed I don’t know because what I have works.
Need to add some functions not in CF or Lucee? Add a jar file, create an object and you are in business. All of the Java world is open to me by this one feature. Need something to run faster, write your own java class and you just extended the language. Back before encryption was built in I write CF_Enigma, a java based blowfish encryption engine. It was easy and fast.
Now there comes another selling point for CF. For a number of years I was a contract programmer. So short term projects. In my travels the average PHP programmer makes $40K to $50K per year. The average CF programmer makes $70K. Big difference. On contract gigs the amounts go up. Around $50 / hour for a good contract programmer is normal and I have seen as much as $90 / hour. Maybe PHP guys pull in those amounts but I have not seen it.
Andrew Penhorwood
–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/dc793a33-4a21-4d29-a0a9-16f279bf81e6%40googlegroups.com https://groups.google.com/d/msgid/lucee/dc793a33-4a21-4d29-a0a9-16f279bf81e6%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.