Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to land my first programming-related job, and I found a website for a company which is accepting resumes for an eCommerce development position.
This is the requirements they listed:
To be proficient in:
HTML (hand-coded)
CSS
PHP
Javascript
MySQL
Preferred skills:
PEARL
Linux
The fact that they (unless they're actually using the PEARL programming language) misspelled perl and have a fairly bland portfolio aside, I can do all of this--I mean, I need to touch up on my Javascript and learn a bit more MySQL--but I can do all this, and I'm sure I can pick up perl in no time. But I was wondering--what exactly does an eCommerce developer do? Is this like, building shopping carts? User login systems? Or does it just mean doing everything except design on corporate websites?
eCommerce has one big word that goes with it Security.
Do you feel confident writing secure code? Bearing in mind that your code will be handling the users credit card information.
Now, there is alot that goes into building an eCommerce solution from the ground up
Product Listings
Adding/Removing Items
Sort by size/shape/price/color/...
Search
Filtering results
Shopping cart (harder then it sounds)
Database or Session?
Adding/Removing Items
Checkout
Integration with payment API
Reporting
Inventory
Security
XSS
SQL Injections
I would suggest that ecommerce is so much more than a specific technology. ECom is more about how the database is built and the features that are required. There is a good book that I read 10 years (a long time) ago that goes into ecommerce with asp classic. But there are many new ones using newer technologies here.
The big key is how you structure your data, products, options, orders, order details, credit card/user data, etc. Also, the various ways of processing transactions. How to handle order pipelines. When to offer navigations away from the current page and when not too. How to make product recommendations. Dealing with tax API's and shipping API's. You might consider downloading DashCommerce (a .net application) or something similar that fits your preferred technologies to see how they have set things up. Install something. Get it set up to feel the pains for data management. ...also to feel the pains of navigating a shopping cart (adding products to the cart, updating the cart, checking out, setting up an account or having an anonymous checkouts).
Being an commerce developer generally means knowing how to work with Verisign (now paypal) or similar payment processing. How to intercept fraudulent transactions and deal with them appropriately. How to work in a high transaction environment (caching, tierd architectures, queues, web services). Cross linking products based on user history/profiling to maximize transactions (think candy at the check out stand of a grocery store). Knowing how to work in a secure manner with sensitive data which generally means encryption techniques, setting up DMZ's, working with proxies, etc. Take a look at using some form of a rule engine for order pipelines so that your business rules are separate from your application logic. Understand coupons schemes, discounts, etc. Frequently ad campaigns are heavily used for generating side income.
Ecommerce can be a big topic!
It all depends on what you are working with.
I have been working as an e-commerce developer for half a year now.
I have used the Magento platform for all of my work.
Since standard Magento is already very secure you won't have to do much security code.
Mostly you change the layout and the design of the standard Magento shop and add any new features the client wants.
Most of these can be achieved by downloading custom modules built by other developers or you can build them yourself. Building a Magento module the right way is quite difficult for someone who is kind of new to programming or new to Magento.
I know this topic is rather old, but i thought someone might still benefit from this answer.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm introducing a new Project-Management software in my company and looking into possible opensource software. Since i'm familiar with python, trac would be my first choice. but it looks like it is mostly used for software-projects, which isn't the case in my company.
Furthermore, time tracking is a big issue. We have multiple develeopers and each one should be able to track their time on the projects he worked on. This times schould be exported into csv at the end of each month (although i think i could to the export also directly from the DB)
So have anyone experiance with trac in non-software projects? It would be great to her some experiance from you, saves a lot of time for me ;)
We currently use Trac for our IT team. It allows us to track things such a help desk tickets, server projects and website changes. We have been doing this for over a year now and it is working great. It is even starting to spread out into other teams for managing team tasks!
As for pulling hours, etc from Trac, we use a custom field and then pull the data through the report module (now deprecated) and direct database access. In the past we have used plugins such as these.
http://trac-hacks.org/wiki/TimingAndEstimationPlugin
http://trac-hacks.org/wiki/TracHoursPlugin
We have also tied Trac into AD for authentication which allows for a single shared pasword for Trac and our domain.
For what it's worth I've setup a couple of Trac instances, that are totally unrelated to software development. Trac works well as a low entry barrier platform for any stuff I've encountered so far. We have all sorts of applications running, and especially the attitude to wikify anything is very nice - wiki markup in tickets, consistent link syntax across modules (changeset comments, tickets, wiki pages), etc. And I can confirm the viral effect, that a well-established Trac application has.
Trac it's very slim at initial setup, but feature-rice and modular from the ground to satisfy growing demand. For things like time-tracking you could use solutions like the TimingAndEstimationPlugin mentioned by Josh before as well. In general trac-hacks.org is a crowded space, not exactly easy to pick what you want, but a valuable resource anyway.
Make sure to ask at the trac-users mailing list and IRC channel #trac at irc.freenode.net, if you encounter some challenges. It's a small developer community, but a friendly one, and with some Python experience you'll surely find your way. Source code and wiki docs at trac.edgewall.org are always your friend.
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 2 years ago.
Improve this question
I work on developer tools for a particular product. There is a competing set of tools for the same product produced by a different company. The user-base is split roughly 50-50 between us.
Recently, the other company has introduced scripting to make their own tools extensible by end-users. This is a feature that we have had planned for our tools for a while, but it is only now that we are able to start implementing it.
My question is: should we try as much as possible to collaborate with the developers of competing product so that end-user scripts can be shared between users on the different products? We would obviously require different implementations, but share the same syntax. This would obviously be better for the community as a whole since there would be more interoperability.
The downside of collaborating like this is that the competing product's scripting language is slightly tailored towards their own implementation. We would have to jump through a few hoops to create an implementation for their scripts on our platform. Or, we would have to somehow convince our competitor to modify their scripts so that they are platform agnostic.
So, to rephrase my question: should we try to collaborate, thus making our community happier, or should we produce a competing scripting language that is more appropriate for our platform?
I realize that this is a very general question with no single right or wrong answer. What I am looking for is a good explanation of the pros and cons of each approach.
I would write something that is specifically tailored towards my own system (don't compromise your technical quality) and then release and fully support a compatibility layer that allows my competitors scripts to run on my system (make it easy for users to migrate).
I'd stay away from doing things that will try to lock people in and cripple them if they move. These tactics worked once upon a time but in this day and age don't really cut it any more. I'd even go so far as to actually (unofficially on fora etc.) help people who are having trouble porting scripts running on my system to my competitors.
Another way to ask the question (and to answer) is to wonder WHAT KIND of script language is DESIRABLE FOR USERS.
If your competitor went a lock-in route with a proprietary scripted language, then please your users (and get a competitive edge) by using a STANDARD scripted language.
Doing so will immensely increase the value of your tool as many persons ALREADY know the scripted language.
Nobody wants to learn a new language.
Would building a unified scripting language harm your customer-base or give the competitor the competitive edge?
Obviously if you want to lock in customers, go solo which will prevent your customers from easily switching over to the competitor's product (sounds a little like Microsoft tactics) or if you know your product is superior, a collaboration will allow you to get customers from the competitor in which case customers will have the choice to choose which business model suits their needs, make a choice based on the quality of the product as a whole as well as which features they really need instead of being locked into an invisible contract due to the choice they made initially.
Going the collaboration route will also put your company in a position where developers will respect your company (for not being a greedy monopoly monster) instead of boycotting it due to their "moral" beliefs in open standards.
I would say that if possible make it compatible, not so much to cooperate but to compete. Making an incompatible solution would lock you customers in to some degree (you don't have any yet with a lot of scripts - so not much gain), but making a compatible solution keeps the door open for customers of your competition to migrate (they might have some scripts by the time you ship yours).
Just my 2cents
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
I'm working at a development shop that is using outdated bug tracking
software. They're currently weighing in on alternatives to replace it.
This software tracks our bugs, as well as tasks for new feature requests.
We build a core application that we configure and support for a variety of clients. In this vein, we do have customer service techs to provide assistance with both core application bugs, and bugs with the client configuration.
Because of this slant towards customer service/technical support, the proposed alternative is Microsoft Dynamics CRM. I have no experience with it, but from what I can tell, it's meant more for client-facing issue tracking than it is for bug tracking and QA from a development standpoint.
Has anyone used Microsoft Dynamics CRM and found that this would be suitable software for bug tracking?
I'm having trouble recognizing benefits of using CRM software to track bugs/tasks. I could understand it for the sales side of things, but I'd think that having separate software for bug tracking makes more sense than bundling everything together. Has anyone else run into this kind of predicament - what was the outcome, and/or persuasive arguments for or against such an approach?
EDIT: Customers don't need to add bugs directly; they call our support desk and we open a ticket. Our current software was extended to do both issue tracking and bug/feature tracking as an all-in-one system. Unfortunately, it doesn't do a great job of it - the break occurs at a source control level. We cannot associate changesets to a bug or task.
What I ended up proposing is using TFS for development tasks/bugs, which provides us with automatic changeset linking, and continue to look down the avenue of using Microsoft Dynamics CRM for customer issues. There may be ways to configure the two to work together, but if not, then a bug would need a comment added with an issue # to correlate the issue to a bug that goes through development/QA/deployment.
Thanks for the answers!
I wouldn't. A CRM (whilst some of them have task tracking and even software bug tracking built is) is not, (generally), developer or product centric, but customer centric.
I would suggest you look at something like JIRA for bug/improvement/dev work tracking. Depending on the size of your team you can get started for US$10.
In terms of customer facing support, if you need to allow customers to directly create issues, JIRA might get a bit expensive. If so you could consider GetSatisfation which allows you to provide front end support and includes integration with JIRA for your internal tracking/dev work.
Using get satisfaction (or an equivalent) can also help you crowd source your product's support process, potentially reducing your on-costs.
CRM is very customizable, and can do pretty much whatever you want it to do. We use it a ton internally... our development items are created, bugs are tracked against those, client cases are opened there, and we track those against bugs and items as well. We've got some initial work done on linking up our source control to it as well, so we can pinpoint the commits that a particular item involved.
You'll certainly need to customize it to get it to work the way you want... that may involve as little as adding some entities and fields, or as involved as writing custom ASPX pages, plugins, and workflows. I'd say if you're looking to leverage other Dynamics CRM functionality in the future, it's worth a look. If you're looking for a bug tracking system to just buy and start using, it may not be for you.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would like to design an eCommerce website with WordPress. I don't want to do it from scratch so I'm looking for a free plugin. The features I expect it to have are:
shopping carts
shipping modules (Canada post etc..)
payment using Paypal
customizable themes
I came across : WP-eCommerce
it claims to be free, however I found out that some documents require payment. All the payments, shipping modules are not free, am I right?
Actually, I'm not very familiar with Wordpress, if possible, could someone suggest an easy to pick up, but powerful enough eCommerce plugin for Wordpress?
Thanks!
WP-eCommerce is the only plugin for WordPress worth looking at when it comes to eCommerce. You do get a lot for free.
That said, Alex makes some great points about how WordPress is NOT ideal for eCommerce.
However, after having completed 2 websites with WP-eCommerce and 2 websites with Magento Commerce, I can say that there is a HUGE difference in the time it takes to complete.
WP-eCommerce can be set up relatively quickly with very little customization to get it to look decent in your own WP Theme. A full eCommerce system such as Magento, on the other hand, has a huge learning curve and you will spend 3 times as long anytime you want to change anything.
It all depends what you're going for. If you want something simple that can be tweaked a little but doesn't need to be a great robust long-term solution, I would definitely consider WP-eCommerce. Otherwise, go for a real eCommerce platform.
Alternatively: Zen-Cart looks simpler than Magento but without some of the flexibility. Whatever you do, DON'T go anywhere near osCommerce.
Trick question: WordPress, a very simplistic blogging platform, should never be stretched into something as intricate as an e-commerce solution. An e-commerce platform offering a simple blogging module is another matter entirely.
Since you don't know much about WordPress anyway, you may want to consider using a e-commerce platform like magentocommerce.com, zen-cart.com, or oscommerce.com. All of them are PHP/MySQL based, like WordPress.
Wordpress.org has an extensive list of all of the various extensions and add-ons that are publicly available. If you look under all results with the ecommerce tag, you might find something that better suits your needs. If you are already using Wordpress as your content management system, why not just outsource the shipping and order management with something like Paypal or Google Checkout? Just have your catalog and if they like it, the can click "order with Paypal" or some such.
Also, I just went and looked up WP eCommerce and it is incredibly generous what they offer out of the box for free. The things that cost are listed at the Gold Cart premiumm upgrades page, and from what I can tell, most of the features you could do own your own, other than the added payment options (none of which I've heard of).
You should take a look at the PHPurchase wordpress ecommerce plugin. It's got great features to sell digital products, physical products, and even recurring billing/subscription products. There are membership management features built in so you can require an active subscription to see certain content on your site. And, perhaps best of all, it is backed by real, professional support. Check it out here: http://www.PHPurchase.com
wp-ecommerce definitely is not the only e-commerce plugin out there, check some of these out before you go the route of using magento or zencart (both of which are a major pain in the ass)
http://sixrevisions.com/wordpress/top-5-excellent-e-commerce-plugins-for-wordpress/
also I hear shopify is good and can be used with wordpress although I've never tried it out
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 9 years ago.
Improve this question
I'm responsible of finding a good way to document the software project I'm working on.
What things are important to document? Should documentation of code and design mainly be in the code in the form of comments? Should we put text files or Word documents directly in the source control togetether with code? Should we use a wiki?
Factors to think about include how easy it is for the current team to create the documentation, and how easy it is for other developers to find, correct and extend the documentation later. My experience from many projects is that developers tend to not write documentation because the system for writing it is too complex or developer unfriendly, and that after a few years, new developers can hardly find the little documentation that was written.
I'm interested in what approaches you have used in similar projects. What worked well, what did not work well, and why?
Some key facts about the project:
The platform is C# and .NET.
We use Visual Studio and Team Foundation Server for source control and work item (task) management.
We use Scrum and test-driven development and are inspired by domain-driven design.
The software consists of a collection of web services and two GUI clients.
Other clients are going to integrate with the web services in the future. The integration will be done by other developers on other teams (so the web services form a kind of API).
SharePoint is heavily used throughout the development environment. Most projects have a SharePoint site, including ours.
On our project's SharePoint site we currently have a bunch of MS Office documents on things like requirements, design, presentations for stakeholders etc. Keeping everything up to date is hard.
We also have a SharePoint wiki for the development team only, where we document things in an unstructured manner as we go along. Examples include how our build scripts are organized, our testing policy, coding guidelines.
The software is an in-house application in a fairly big financial institution.
The software is developed by a team of six people over a period of ~1 year.
The developers are consultants hired in for this project only, and will not be available to help in the future (unless the client decides to pay for it).
The client has few guidlines for how this kind of project should be documented.
I think the most important things to document are the decisions. This goes for everything from requirements to architectural choices. What are the requirements of module X? How are these requirements represented in the architecture? Why did you choose architectural pattern A over B? What are the benefits? The same goes for source code: it is common knowledge that commenting the why is way better than the how.
How you document these decisions does not matter that much in my opinion, whether you use a Wiki or a Requirements document made in Word. More important is that these documents are always up-to-date and that it is easy for anyone to access them. This can be achieved by using a wiki, or placing the documents under source control, as you say. If only a few have access to them, they are more likely not to get updated, and not to be read when necessary.
We use a Wiki for our current project and it works very well. It is easy to access for anyone (developers, managers, and customers) and a history can track changes, so you know what has been changed and why. Furthermore, we try to document the code in a meaningful way and document the major design decisions. We try not to document too much, e.g. minor things, as it is always hard to keep those things up-to-date and it is not worth the effort, imho.
Worst for me than lack of documentation is excess of documentation.
Keep in mind that yes: it's really important to document your project, but also that the major part of your documentation is always at risk of never been read at all.
So, I think that a good starting point consist in thinking of your documentation more like something that you may use to introduce new developers to your project than an over detailed description of the inner workings of your software.
G'day,
Definitely use a wiki. I'd recommend TWiki as it's an excellent and extensive implementation of a wiki without being too complicated to install and manage.
Here's a couple of initial thoughts.
Categories:
Start off with an initial ontology of what you want to capture but
allow people to add new categories or sub-categories as required,
allow people to retitle (sub-)categories as required and maybe as agreed for this one so you don't get fragmentation for multiple names for basically the same thing.
let any initial (sub-)categories wither and die if they are left empty. Do this at the end of the project as some areas may only have entries towards the end of a project.
Tagging:
Start using a tag cloud. BTW here's an excellent plug-in available for TWiki to start classifying content early on in the project. Retrofitting tags is almost impossible to do. Starting tagging early also allows people to search for information that may be there already rather than having the same info located in multiple places.
HTH I'll come back and add more points as I think of them.
First and most important, have the comments written in such a way that NDoc can parse them. This is the best way to have the code itself documented, as the developers have to change their development practices very little, and you can generate pages that explain the code without having to look at the code.
Second, getting developers to write documentation is not easy, and getting them to do it might be an exercise in futility. This is where products like Fogbugz come into play. They will help manage the development with tickets, help track check ins, and when your done an iteration, generate release notes.
In conclusion, your best bet is to find the most effective solution that fits in with the devs existing process. If it impacts their development process very little, they will be more likely to adopt the system.