Xojo in 2017: A Review [Part 4: The Community]

in

This is the fourth part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3

-----

Bob Keeney writes in his latest piece that “software development is fluid” [1]. Always changing, evolving, and not easy to schedule around. It is a nice analogy and I get the underlying message. There has been a current on the forums that maybe Xojo does not do enough to resolve bugs. Perhaps they are too focused on new stuff that important issues do not get addressed. Bob is writing a piece here defending Xojo, their development style, and the complexity of what they are trying to achieve.

I think like most in this niche of software consulting we rely on Xojo being a reliable product. Our success in some ways is tied to theirs. Let me rephrase that a bit: Xojo consultants would prefer to stay Xojo consultants versus primarily using other tools. He wants to promote the tool he likes so much and so do I. Most in the community are like minded in that way.

Many of his arguments I suspect are valid and reasonable. I think for the most part you see this throughout the Xojo community. We all recognize how challenging it is to run a small software company. Some part of us appreciates Xojo on a fundamental level. We also become have become proficient with it and it enables us to get more done.

However, there are times when it holds you back. A new release breaks something or a new feature does not work as expected. The community lights up then and the argument remains:

  • Why do you not give us more heads up on what you are doing?
  • Why do we not get more time to test?
  • Why are there not more testers?
  • Why do bug reports take so long to get fixed?

It can get pretty excited at times and it is not unheard of for a thread or two to get locked shortly after a release. I love this part of the community because everyone is so invested in the product.

When you look at issue trackers and forums for open source languages it is rather dull. Many times there are few that are invested in a language because you are only one console command away from installing an entirely new development stack. The questions are highly abstract and technical and the responses are typically slow and methodical.

I comment aggressively on the Xojo forums that I wish the (Xojo) engineers would tell us more, show us more, give us more. Sometimes they fire back and have told me that being on the forums is not in their job description. Nonsense. If the Xojo engineers left the forums the community would be harmed. The Xojo engineers are not just part of Xojo they are also part of the community. They would miss us as well.

We all want to enjoy where we work. We push Xojo pretty hard and that is healthy but we also have to make sure we are not making it intolerable to work at Xojo. Like Bob said we need to do our part with bug testing, writing open source code, and helping others in the forums. However, the community is not to blame when regressions hit and progress slows. Some part of it is due to the enormous nature of what Xojo is trying to accomplish. The other part is the secretive nature in which they do it.

This is why in Part 2 of this series I suggested open sourcing the standard library; The mish mash of libraries and classes in either Xojo, C++, or third-party libraries. When bugs are encountered in the “framework” it can force you to use a different version of the product. The sad truth is regardless of the difficulty of a bug report it may not lead to a timely resolution. Often times you will get a confirmation and then wait several releases. You have no idea if they have even scheduled to start fixing it.

I feel like if Xojo is not going to commit to fixing something in a reasonable timeline then that would be a great opportunity to ask the community to attempt it. Let us earn badges or points or something. Give the top 5 every month a coupon for example. I am thinking bug bounty board meets achievement points. We don’t need any cash or prizes but recognition to the community for being involved. Most importantly let us help you chisel away at the issue list.

If there is a problem with Bob’s piece I would say my only nitpick is I don’t think software development is fluid at all. In fact, I think it is solid. Solid like a giant rock that has remained stationary for millions of years.

Software development is like sculpture as you chisel 0’s and 1’s into a rock face. You spend so much time planning and considering the subject matter and problem at stake. You design and architect the database, storage, and architectural nuances of how messages get from one method to another. You consider deployment strategies and security concepts to protect your users and not leak your database to Reddit. You do all of this in the hopes perhaps you will achieve something great. “Something great” more often than not is a tool or utility to create more software to manipulate even more 0’s and 1’s. 

I say solid as a rock because even with source control, undo, snapshots, checkpoints, auto-saves, and screen recording you can’t save a bad program. It takes too much work and the amount of effort to resolve the plumbing job of a poorly planned program is terrifying. You start dreaming up ways to convince your client or boss that it would be best to start anew. As you mature you realize this is not always a practical strategy and so you are going to have to do surgery more often than not. You are desperately hoping not to chisel the last bit of support that keeps the rock standing up.

I am not convinced software is fluid at all.

I am convinced Xojo makes for a great chisel.

I also believe the Xojo community is part of the value proposition of the product. For example I search the forums before I search the documentation. Thank you forum.xojo.com. 

-----

[1] = http://www.bkeeneybriefs.com/2017/08/software-development-is-fluid/

Serving static content from Xojo Web

in

Now available on GitHub is open sourced code to help you serve static files from your Xojo Web application. This is especially useful if you are running standalone or load balanced apps and do not want to depend on another web server.

Check it out here: https://github.com/1701software/XojoWeb_StaticContent

For example at ServerWarp we host many load balanced applications for customers. Many will produce PDF reports for users. In order to serve those PDF reports they have often relied on writing those PDF files to another directory of another domain or subdomain because Xojo Web could not natively serve those files. Technically the "WebFile" class works for this purpose but the user and development experience is a bit subpar especially for mobile clients. You can only access files that way if you have an active Xojo Web session. What if you want to email your user a link to the download?

The problem at ServerWarp is we isolate your apps and domain web servers from each other to protect from vulnerabilities and provide the most secure environment. So it requires extra configuration to get your Xojo standalone app to be able to write to a specific folder of another domain. The other obvious downside is you now need a secondary web server and domain/sub-domain to serve these files. It would be great if you could simply write your static files to a sub-folder inside of your app directory and serve those files directly. That is exactly what we deliver here.

The code we are presenting on GitHub today allows you to easily map folders to the Xojo Web application to be served as static content. It is a drop in module that extends the 'App' object of your Xojo Web project making integrating it super simple.

The example project demonstrates two distinct static folders with a PDF, image, and text file. It demonstrates how to map the folders and the Xojo Web app presents links to test the functionality very quickly. To give you an idea of how it is to integrate check out this screenshot of the 'App.HandleURL' event handler: