IMHO the site is running unacceptably slowly given the low number of users. I'm feeling pressure to improve it sooner rather than later given that at times when we get four or five people posting to the forum at the same time things really slow down. (I know why it's happening and I can certainly fix it, it'll just take time.)
I also need to rebuild the daily digest, which is currently turned off.
And there's the relatively long list of bugs that need to be addressed, most of which are in my godawful rich_textarea widget that we use to enter these posts with. Surprisingly, because browsers suck so badly, that editor widget is the most complicated time consuming piece of the entire project. It took me a month of hard work to get it in the shape it's in now. I know that sometimes the backspace key doesn't work and sometimes the arrow keys don't work and I know that under MSIE it's displaying lines a double spaced. While annoying, these aren't entirely show stoppers meaning that I don't strictly need to address them now.
And then there's the maps support. I really want to get a basic map editor built so we can start sharing roads/rides sooner rather than later.
My inclination is to focus on getting the maps and ride planner built asking us all to deal with the bugs and slowness in the interim. My feeling that's more important at this juncture. (I will fix ALL bugs; I'm just polling for priorities.)
What do you guys think? Bugs, Speed or Maps first?
The Original Miles-By-Motorcycle Group
established 11 years ago
You must be logged in and belong to this group to post to this forum.
IMHO the text editor bugs are minor and should be dealt with later. I'm much more interested in getting the mapping stuff up and running. Speed will then be more of a concern, since there will be much more use. Is anyone else noticing any issues with speed at the moment? I haven't noticed it, except when it was pointed out. It's not deterring me from using the site at all, at this point.
Maps! I haven't observed any slowness and if the textarea thingie is slightly problematic, so be it. With cool map stuff, nobody will ever talk about how their arrow key didn't work in the 'reply' form.
I would say that some incremental improvements in speed (assuming they don't eat excessive amounts of time/energy to fix) are probably important, especially with regard to new users/first impressions. For better or for worse, many people coming to a new site (no matter how compelling, promising, etc.) will make a quick and nearly automatic choice about staying/returning based on initial experience. One of the prime determiners of that choice will be speed. If site response is too slow, it may end the relationship with a potential new user before it even starts. One easy/time effective way to pick things up a bit might be to do some quick surgery on xeon--a brief/cheap HW upgrade could make a significant performance difference, and thereby provide breathing room for other upgrades and improvements.
yea, 
buffalo, I agree. The performance bothers me the most so that's what I'll focus on first.
I mentioned in the other post that I think I can get a 50%, if not more, reduction in page load times pretty easily and that's what I should do first. After that performance gains will become more challenging.
buffalo, I agree. The performance bothers me the most so that's what I'll focus on first. I mentioned in the other post that I think I can get a 50%, if not more, reduction in page load times pretty easily and that's what I should do first. After that performance gains will become more challenging.
I should point out that, of course, I can make this code fly on whatever hardware I have access to. It's a tradeoff between performance and flexibility/maintainability.
As I've mentioned elsewhere, I've created my own programming language called FVML which is the glue that holds this entire platform together. It's very flexible and for the typical kinds of AJAXy things that I like to do it takes care of all the glueing together of pieces so that I don't have to worry about any of that. Literally, if I want to add a like button to something all I have to do is type <like> in the FVML file next to the thing and it's done. The same is true of all the other features. That cool dropdown in the upper right? That's a <popbox> in my language. The dropdown for notifications including the calling to the server and getting the notifications list, etc is only:
(The amount of code that this turns into if I were to write it by hand would be several pages worth.)
The code for the messages dropdown is almost identical. Back in the day when I first created this language, I imagined getting web designers to use it. It's almost identical to HTML so I thought it wouldn't be too much of a stretch to teach them simple variables and if statements. (The language also handles loops and other structures.)
But of course, my plans of world domination didn't really take off and only a handful of web designers have ever worked with this language (and they have turned into real programmers in the mean time.)
However, despite never reaching my target audience, I found FVML to be very convenient. I can build a bit of functionality, create a tag for it and suddenly I have a new widget in my arsenal which I can quickly deploy everywhere. It makes it so that with each feature I add building subsequent features is that much easier. For instance, the Like link that's plastered everywhere is a tag, as I've mentioned. Build it once and I can drop them everywhere no problem.
Unfortunately, this flexibility incurs a performance penalty.
At this stage in the project, my thinking was that this flexibility is key because we don't yet know what form this site is going to take. So the flexibility allows us to quickly experiment with new ideas and let's the site morph more easily as it needs to.
Once it stabilizes a bit, we can then go in and start optimizing those parts that perform the worst and I have a number of approaches to doing that with varying levels of difficulty vs performance gains.
As I've mentioned elsewhere, I've created my own programming language called FVML which is the glue that holds this entire platform together. It's very flexible and for the typical kinds of AJAXy things that I like to do it takes care of all the glueing together of pieces so that I don't have to worry about any of that. Literally, if I want to add a like button to something all I have to do is type <like> in the FVML file next to the thing and it's done. The same is true of all the other features. That cool dropdown in the upper right? That's a <popbox> in my language. The dropdown for notifications including the calling to the server and getting the notifications list, etc is only:
<popbox class="popbox" dom_id="messages_dropdown" href="/_fvc?COMP=messages&cmd=index&popup=1">
<opener>
<div class="messages">
<span if="$THREADS{COUNT}!=0" class="notification_count">$THREADS{COUNT}</span>
</div>
</opener>
<popup>
<div class="popbox_content_container messages_menu">
Loading ....
</div>
</popup>
</popbox>
(The amount of code that this turns into if I were to write it by hand would be several pages worth.)
The code for the messages dropdown is almost identical. Back in the day when I first created this language, I imagined getting web designers to use it. It's almost identical to HTML so I thought it wouldn't be too much of a stretch to teach them simple variables and if statements. (The language also handles loops and other structures.)
But of course, my plans of world domination didn't really take off and only a handful of web designers have ever worked with this language (and they have turned into real programmers in the mean time.)
However, despite never reaching my target audience, I found FVML to be very convenient. I can build a bit of functionality, create a tag for it and suddenly I have a new widget in my arsenal which I can quickly deploy everywhere. It makes it so that with each feature I add building subsequent features is that much easier. For instance, the Like link that's plastered everywhere is a tag, as I've mentioned. Build it once and I can drop them everywhere no problem.
Unfortunately, this flexibility incurs a performance penalty.
At this stage in the project, my thinking was that this flexibility is key because we don't yet know what form this site is going to take. So the flexibility allows us to quickly experiment with new ideas and let's the site morph more easily as it needs to.
Once it stabilizes a bit, we can then go in and start optimizing those parts that perform the worst and I have a number of approaches to doing that with varying levels of difficulty vs performance gains.