I had never had to deal with FileMaker before I started at my current job, six months ago. Since then, I've become relatively familiar with it.
We've been having some issues with our Container objects dropping references to files, and I have been working on a solution of my own. Well, someone told my boss about 360Works SuperContainer, and he told me to check it out.
It seems to me that SuperContainer is just a virtual server for organizing images. The way that our image database is set up, it would be no hassle at all to just create a field that returns an image's path based on the item number, then pas that to a Web Viewer - which is basically all that SuperContainer does, anyway. Given that I could explain to some of the other employees how to put images in the database correctly, nobody would ever have to manually add an image through FileMaker again. We're not really very interested in the FileMaker Instant Web Publishing features, either, so there's that.
Right now, I'm having a pretty hard time justifying spending $200 of my company's money to pay for additional software that does something that I'm already taking care of. Are there any ground-shaking, game-changing features of SuperContainer that I'm just not picking up on? (Keep in mind that I can batch-process images down to thumbnail size for free with XnView, or that, if push came to shove, I could easily build a webapp to make an in-program slideshow of pictures.)
What do you guys think?
You're right. SuperContainer could help to deal with the dropped references when storing files in FileMaker by reference instead of storing the entire file within the database. Personally, given how large FileMaker files can be, when working with documents, I tend to simply store them within the database and script their retrieval. But SuperContainer isn't doing anything that you couldn't do yourself with scripting and a web server. By using SuperContainer you might save yourself some coding time, which might make it worth the purchase, but it won't add any capabilities that you couldn't code yourself.
Related
We are working with a DDD framework in our company. We are changing a lot of core things in our API because we are still growing and we are still in our enfant phase when designing a good API.
The problem is that there are alot of flows already in the same api. Which are not compatible with eachother.
We have an order service and a product service.
Normally when the product model radically changes, we have a major impact in the order model.
Now im here listing all kind of red flags which should never happen but I simply dont have control over how it needs to be done. That is pretty much management pushing for a fast solution. And leading to bad shortcuts...
The way is has been decided to overcome that Order needs to adapt constantly. They made a property in the orderline called productConfiguration. This is in the contract of the service and is direcrtly translated as is in the DB tables. This contains the product model that can change. In json format.
For me its very clear that this is very dangerous to do this. Because i nthe end you need to change this json into an actual object. So you just move the restrictions from the service contract to code logic. Which makes it worse cause it will only cause an issue at run time...
Are there other major things I just know about, so I can bring it to the table to avoid this way of working...
Using strings that are directly converted into DB tables is not just in your opinion a bad design. It's an opinion shared by a lot of us.
What do you do when an object changes? For example, the new one requires an attribute that the old one didn't had. How do you manage this situation? I suppose that you've to change everything, including the objects stored before. Or build a kind of transformation layer where you translate objects from the old to the new design. A lot of extra work.
Anyway, given that the two domains are separated, what are the information that change so much and require such a design? I mean, for most of the things you could know at the beginning what do you need for your part of the domain. For the rest, I would prefer to have a kind of service that given an Id gives you the information from the other domain. You can change this service (here could be also json obj, if nothing than just showing is required) and adapt to your/their needs. But, it's just a solution that comes from my limited knowledge of your processes.
Other ways are also possible, as long as you can always understand which version of the design are you using.
I have sort of agreed to help out a small local community non-profit org with a database that was created for them many years ago. The original developer, along with his original uncompiled files are long gone, the current file has many problems, but since it is a .mde file I can't pull it apart to see how it all works. I do have access to the Tables and I can see what the Reports look like (just not how and where they get the data).
My feeling is that it might just be easier (and quicker!) to create a new version using what I can see in the original database as the basis for the new one. This way whatever problems they are experiencing will be resolved and all of the legacy stuff they no longer need/use will be removed. Plus, they will have a version that can be modified in the future even if I'm not around.
If you've had to deal with a similar situation how did you go about deciding which direction to head in? In other words, what are the typical considerations/traps I need to know about before taking on this adventure (other than it taking way more time and effort than I think it will)?
Thanks!
I'd first determine if big or minor changes are needed now or to be expected in the near future. If not, I'd try to find a way to keep the system alive.
On the other hand, you already provided some good arguments for setting up a new system that I agree with. I would add to that that is much more satisfying to do this. Almost always you wish you started from greenfield if you try to alter an old legacy system.
Point to considder, is that you might need to train the existing users to work with the new system.
Good luck!
A bunch of work is done for static pages that will not contain dynamic data, such as, contact, about us, home, etc. that can be updated fairly easily if the designer/developer has access to a site. Why is it a better practice to keep that information in a database that must construct the data on the regular?
If one thinks in terms of templates and a website administrator who is a lay person, then the database format in Content Management System makes more sense, because all the person has to do, for example, in order to change contact details on the Contact page, or change some updates on the Homepage, is to go into the CMS. It will be set-up in a Form type of look, that only needs filling in and submitting. The initial cost for a small static website with a CMS setup will be higher of course. However, if your homepage needs regular updates, it might be worth having a CMS. If there are very little changes throughout the year, one may opt to hire designer/developer services.
Rather than best practices, I would see it as cost and demand.
Because putting the content in the database and dynamic generation a the pages for each requests solve a lot of other issues. Cache invalidation is a hard problem. A static site where every page is build with different pieces of content from multiple sources (in Drupal: blocks, users, nodes, taxonomy terms, etc.) is like a gigantic cache.
But if you don't need the flexibility and the features of the CMS (like letting nearly non-technical users edit pieces of content), then don't go with CMS.
"A bunch of work is done for static pages that will not contain dynamic data, such as, contact, about us, home, etc. that can be updated fairly easily if the designer/developer has access to a site. Why is it a better practice to keep that information in a database that must construct the data on the regular?"
There are probably 3-4 key points to consider here.
First, why do people use WordPress? In many cases it's because they aren't web developers themselves and they don't want to have to hire one every time their board of directors (say) changes. I have several clients in this category. By putting the content in the database and rendering it in a template, non-technical users can manage their own pages as well.
Second, consider how easy it is for someone like you to create several static pages and simply use WordPress to power the blog. There are no shortage of startups and small businesses (especially in the tech space) that do that. Use something like Wappaylzer to see what folks are using.
Third, it's not a best practice to keep static information in the database. That's why page caches exist (along with static asset and opcode caches... no one recommends recomputing things unnecessarily as a performance best practice)
Fourth, consider the implication of removing the ability to edit pages from users. Or requiring them to know HTML. And if we start dealing with revision management as well, they might also need to learn Git. I for one hate having to help clients solve problems that they really should be able to solve themselves. I'm much happier if they can manage the simple things on their own. They tend to be happier with their websites, and I tend to get more interesting projects... good all the way around.
In sum, it's not a best practice for some people. Which is why some people don't do it that way. It's not a best practice to return to the database for static assets either, which is why folks who are reasonably aware of caching don't do it that way. But it is a good practice, at least, to let folks have greater control over their websites. It comes at a cost, and it's not right for everyone. But it certainly is right for a lot of people.... and maybe a lot more than simply "right." I think you could go so far as to say it's empowering, and one of the best things about WordPress in general
I'm pretty new to HTML5, and want to know if this is possible.
I want to be able to create a canvas in which I can load an image in it, and then draw on it for other people to see, and allow them to make changes to it as well.
It doesn't have to be super complicated with lots of different tools, just basic stuff. I just want to be able to change the image every now and again.
Is this possible, and if so, can someone point me towards a tutorial of some sort?
Do you already know how to do non-image collaboration?
The way you do collaborative editing of any medium is pretty much the same.
The main difference between one medium and the next is the content of the updates (DOM elements vs. paint events). The other big thing you'll run into has nothing to do with the medium, but whether you want to use AJAX or WebSockets or what have you - this is a question more about the method through which you accomplish the collaboration.
The essential concept is (from the user's perspective):
Submit my own changes
Check periodically via AJAX to see if anyone else has made changes, or use WebSockets/long polling to be notified immediately of changes from others
Update each person's view with the changes from other users
Figure out a way to resolve conflicts if two changes are incompatible, if this applies to your problem
Provide some way for users to "undo" things
Not to blow my own horn, but last year I wrote a collaborative scratch paper/brainstorming app called cortex, and I blogged about each commit and how I figured out how to do the realtime collaboration. I did it in Rails using an AJAX approach, but the concepts I used for real-time collaboration are applicable to most any app that wants to take a similar approach. This post includes a video simulating two users collaborating on the same page, and how soon/how often updates from one client are shown on the other client browswer.
cortex isn't the prettiest or most advanced thing in the world, but I think it's a good intro app to get the concepts down. It may not even be the best designed (it was my first collaboration app), but I use it nearly every day and it seems to work well enough.
I am building a Flash AS3 application that allows users to modify images, (drag and drop, select, scale, alter saturation, etc) and then submit-save them to a server.
The user will then have the ability to log in and access these saved images via a separate admin tool in a thumbnail gallery. They can either delete an image or click a thumbnail to view it at original size.
I am architecting and building the front end only and will have design ready assets supplied.
Since I have been burned in working to fixed quote before, would appreciate ANY feedback advice on quoting this project!
Thanks in advance!
I've done a lot of estimating, and I've found that the only way I can get a reliable estimate is to break down all of the tasks and subtasks to as granular a level as I can, estimate all of those elements, and then add it up. This usually takes me several passes, and a couple of times waking up in the middle of the night.
It's time-intensive, but works out really well in at least three ways.
Obviously, the first way is that you end up with a pretty reliable estimate.
You also think of all kinds of things that you wouldn't have thought of if you hadn't sat down and wrote everything out (which is a big part of why estimates turn out to be wrong, in the first place). You also give yourself the chance to really think through your overall approach, and you end up making better decisions on things like which framework to use.
Writing everything out to the detail level helps a lot in sequencing the work you're doing with the work of other teammates. Makes it easy to see that at a given point you'll be roadblocked if you don't have an API from the server team, etc. Also helps you realize how you will potentially roadblock your teammates, and gives you the ability to deal with that.
Hope that's helpful. Making myself work hard at the estimation end of a project has really helped me be successful in the actual development aspect.