Please Bear with me as I know It needs research from my side but still want to ask as It would make things a lot easier for me.
Here is what I want to implement.
An online shop where I would configure admin areas for different store owners (vendors). The store owner can belong to same area or different areas. Using the admin area, each store owner can select from pre-configured list of products and define prices for the products in different locations where they have a physical store. The end user can browse the products listing based on his location (area). If multiple vendors belong to same area as customer, the customer will see the product with multiple prices from different vendors. If none of the vendor configured the product of that area, customer will not see the product.
Now the question is, what would be the appropriate option for the above requirements.
Magento, Opencart, nopcommerce or something else?
This is based on my experience. My advice, if you want sth that goes beyond minor tweaks and a couple of new features, stay away from opencart for the time being.
First of all, you will have to pay (not little...) for extensions and mods of often low quality and crappy support. You should also feel lucky to find one that will cover all the features you want and interoperability between extensions is just non-existent. And if you ask for more features chances are you will have to pay again. There are some free extensions but most are a joke. Like, put a link in your footer or disable sth.
So your next option is coding. Opencart is easy to learn if you know basic php and you can start writing code fast. But.. Opencart lacks a solid mechanism for extending it (until v2.0 at least) and after a while it gets both chaotic and frustrating. Also, you will often need to implement stuff that needs some basic backend functionality from opencart but which is either offered in a way that is useless to you or with basic needed features absent. As a result you will find yourself creating your own "library" of functions that will allow you later to focus on your extension. Moreover there is actually no framework on which you can rely. Sure there are some functions and some methods that you can use, but that's it.
Another thing. The opencart community is not one of the easiest to go along with. I don't mean they are bad or that they will bite you, but people there try to make money and do not find it easy to share things with you, be it advice or code. Also, they are competitive. And they do not accept criticism, even suggestions, gladly. And there is a scent of eliticism in some threads that can upset your stomach.
This is how I have experienced opencart. I have to admit that I like opencart itself and I find pleasure in coding for it and even now I am debugging some new extension of mine. But often it reminds me that there is so much lacking and I often spend so much time doing trivial stuff that it makes me wonder if it is worth it.
I do not know about magento. It feels similar to opencart to me.
I would suggest drupal to anyone wanting to implement something custom. There is all a framework and powerful free as in speech extensions and a great truly foss community. There are a couple options there for building an eshop but I would go with the commerce module. It takes a while to get used to all the concepts but you can achieve what you want with just mere clicks. You won't even have to write code if you don't want to.
Again I repeat, avoid opencart if you need sth too custom (as you do). If not, opencart is one of the fastest to deploy.
Wordpress kind of sets the standard for great interfaces for end-users. Drupal is a little more mixed: it is a great experience if the developer updates the UX when they update the site functionality. Concrete5 and other CMSs basically exist soley on the merit of their end-user experience.
Where does ExpressionEngine fall into the mix? How much control does a non-developer admin have with EE, and how pleasant is that interaction for them?
That's really up to you. The backend of EE is completely customizable. It's a blank canvas by default, so you get to build your own backend that is fully customized to fit the exact needs of the client. You can give them more or less control as needed, and you can create different user groups that see different things (including different modules, different menu items, different channels, even different fields within a channel, etc.)
If I'm working with a client that needs a fairly straightforward site (read: brochure site/portfolio site with or w/o blog) and they're not terribly computer savvy, I almost always go with EE because I know I can make it dead simple for them to update their content. For users with a little more knowledge, I tend to give a little more flexibility. It's really up to you how you set it up for them.
I've never had a client complain that EE was difficult to use, and most are actually really surprised at how easy (and some use the word "fun") it actually is.. great confidence boost for people who have always had difficulty updating their site in the past or had to rely on others to do it for them.
Hope that helps :)
I'm working on a travel site and am interested in adding some functionality so that visitors can easily click on a travel destination and add it in a "bag", pretty much like a shopping cart on traditional e-commerce websites. When a few destinations are added the customer should be able to type their own text along with the picked destinations and then send an offer by clicking a button.
A travel guide will then receive the form data to customize a trip for the potential customer.
Every destination in Joomla has its own article and therefore need some sort of button that the user can click to add trip to the "bag". If this functionality is inserted in the article by some piece of code or if it's a module in the sidebar doesn't really matter.
I have tried using "SimpleCaddy" for Joomla. I have modified it but I find it really hard to turn it into something useful.
I would like to know how to best proceed? Are there perhaps any extensions, (commercial or non-commercial doesn't matter), that can get the job done?
Most definitley there are. You tagged you're using joomla 1.5, Virtuemart is a great e-commerce solution for that version. Hugely popular, well supported, large community extremely customizable... the downside is that it can be very complex if you're not sure what's going on. Simple Caddy is a great one for something really lightweight and easy to get up and running quickly - but it lacks any sort of advanced features.
Unfortunately in my experience finding one that blends between 'lightweight and easy', and 'full featured and complex' is very difficult. you may also want to try JoomShopping however - I've recently installed it on a site and had great success with it. It was really straight forward, setup was not too bad and getting it configured just took a bit of trial and error (unfortunately there are no real good tool-tips or anything to help you figure out exactly what does what on the back-end).
Those are my two recommendations; Virtuemart or Joomshopping. They both have shoppingcart features which I'm sure you could easily modify to be the users 'bag'. Both seem to have a pretty good/proven track record and a well rounded community. I think either way you'll be satisfied, but it does sound like SimpleCaddy may come up 'just short' of what you're needing.
This is a little vague, but I hope I'm allowed.
I'd like to get a feel for what the Magento developer community thinks of the Widgets API. Are they clear or confusing, useful or useless. The more detail the better. Do you use the feature? If not, why not? What don't you understand about the feature? etc. etc.
When I say Widgets, I'm referring the programatic APIs specific to the feature.
Yeah its definitely something we have wanted to take more of a look at but we haven't set any budget aside to actually investigate. I would love to create some little widgets that we could utilize for each client instead of having to create blocks that the client then has to pass data to inside of a static block. I looked into it about a year ago and just haven't looked back.
The funny thing is now there are a lot of widgets out there in the community, yet you still don't hear anything about them. I guess we just need more articles about them, which I am sure after you write one, we will all get it :). Basically people don't have time with how busy they are probably to investigate the Widget API fully enough to utilize it. And since there isn't a lot of knowledge base information about it, you don't see a lot of people using them.
I as a developer understand the usefulness of this API and it is not harder to use than any other thing in Magento. I have used it a lot cause I can understand the feature.
But me as the person who has to explain what is a widget or why I made something to be a widget, how should a user or designer use it, why there is a block and a widget side by side and what's the difference. Then I tend to think that this is a total disaster and we should have only widgets or only blocks or one common name and just some type/attribute/value that distinguish static and dynamic version of widgets so I could say : "Hey this block/widget you can drag or include wherever you like in your site and this one you can't"
I was excited about the widget feature when it came out. There is decent documentation available, and I was quickly able to code my own simple widgets. Since then, however, I never actually used widgets in my projects. I have never really understood when to use widgets, and I almost forgot about them.
I feel like we need articles and examples to show the usefulness of widgets. I need widgets to pop up in my head when a client asks for features that can be solved using widgets. Recently, a client wanted to have some text in the footer on the home page. I created a static block and declared it in layout/local.xml. With widgets, this could all have been done from the backend.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
If this is the case, are full blown product backlogs or use cases a little overkill?
How does one efficiently appropriate
his/her time to each respective role?
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into
OOA/D?
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.
The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.
From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.
As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.
Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.
Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
I have two lists of features:
A high-level view which states the scope of the finished product
A list of the features which I'm implementing in this iteration
Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.
I did however try to investigate/make a business-case for the project before starting coding.
How does one efficiently appropriate
his/her time to each respective role?
I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.
Apart from that, my cycle is:
Implement more functionality
Integration-test it
[repeat as above]
Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into OOA/D?
I started with working part-time or in my spare time, to make sure that I had:
Understood the required functionality
Made significant architectural decisions
Written any throw-away prototypes as necessary to learn new technology
After that I was ready to start developing full-time.
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.
It seems that when I leave the project
for some time and come back, it is
extremely hard to get back into the
rhythm of what I was doing.
You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.
If I know the requirements (at this
current time), do I record them
anyways?
Yes, for the same reasons stated above.
how do I manage these requirements?
A feature list is OK, provided you have enough detail in each feature to jog your memory.
How does one efficiently appropriate
his/her time to each respective role?
Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.
What would be a normal flow of events
that one would follow?
That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.
What diagramming/modeling would be
sufficient for this level?
Sufficient diagramming/modeling to make the project clear in your head.
What steps, documentation, and other
project related activities are needed
to help bring this project from an
impractical, hobby project to
something more professional?
Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.
Good luck!
If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.
That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.
That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.
As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.
This is how I work, YMMV:
Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders
Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.
Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.
Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.
And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com
Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.
That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.
It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.
Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...
I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.
VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
time tracking tools (e.g. Toggl.com)
write a lot of acceptance test and use acceptance testing frameworks
Of course these clues also fits in non solo development :)
As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.
Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.
In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.
Specific tools that I'd recommend:
A distributed version control system (much less overhead than centralized)
The most lightweight platform that you can use that has good tooling
A Wiki to easily capture and maintain small and large bits of content
Whatever testing framework that you can use, right from the start of the project
A lightweight TODO list system that you can access from anywhere
I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.