Then run `npm start`, will automatically open browser in `localhost: 3000`.
##What you thought would be hard but was easy, and what you thought would be easy but turned out hard?
Realtime bidding seemed hard in the beginning as none of us has any experience in large-scale web service, let alone realtime communication and concurrencies. It turned out that, by using a websocket, server-client interaction can be largely simplified as exposing port to clients, handshaking, and exchanging messages.
As for things turned out not so easy, we found collaboration in developement, distributing tasks, merging codes, tracking issues and publishing changes surprisingly hard. Often time, we found ourselves lost in communication -- either having different version of code or having different understanding in the agreed APIs. To solve the problem, we have spent extra time setting up development tools like Trello, Git, Maven, and NPM. In the end, we believe the extra work actually facilitated our development cycle.\
##Proudest Thing
During the time we worked on the project, we feel like a software engineer, and that is the proudest thing in this project. We solved problems like a software engineer and we work together like software engineers.
The way of feeling like a software engineer is not just getting better in coding, but in thinking. Systematically organized a project, as well as consistently tackled every single issue.
We started the project all over. Design system, created database, implemented frontend, all the thing, and in order to make all parts work like a thing together we had to solve every single bug. At the end of the quarter, we are able to deliver a good result, and see that all functions we implemented do work, at that time, we feel awesome.
##Things can improve if we have more time
As Steve Jobs said, you have got to start with the customer experiment and work back toward the technology - not the other way around.
The user experiences is crucial in an online application, and we think we can do better if we have more time. Such as internal message, like if buyer want to have a conversation with a seller, or asking a help from auction service; recommendation system that can help buyer find what they really need, and offer an appropriate price for sellers’ item etc.
##Pain Points (technical and organizational)
When we are designing and developing the project, we found actually writing the code is rarely the cause of pain (actually it’s quite enjoyable!). Because we already know the logic to use and depending on the stack we can either code from memory or look up the syntax we need on demand. Well we found other 4 pain points that are:
1. Requirement gathering
- This is the most important one as to define what we are trying to build and why we are building it. We gather requirement from tools like feature requests, user stories, etc. However, I would rather say it’s a critical start point because it it isn't the first pain you experience then that might actually be a sign of a bigger problem coming for your project.
2. Estimating level of effort
- Most people will guess far too little time, so we have to rely on our experience with similar projects and/or tasks that you think should be relatively comparable knowing you will be wrong in both directions on various tasks.
3. Setting up development environment
- Depending on the stack that you choose to use to develop your application, getting your development environment setup can be a real pain. It's not just the local environment (for instance getting visual studio running) but usually we have to worry about connecting to various third party internal or external applications and servers as well.
4. Testing
- From basic unit testing to end-to-end testing for whatever reason this is painful for developers largely because it's a bit mundane and it's almost always under appreciated by the client or project stakeholders.
##Value of Design - Code - Refactor
1. getting a quick picture of the important entities in a system
2. seeing whether you have too few/many classes/features
3. seeing whether the relationships between objects are too complex, too many in number, simple enough, etc.
4. spotting dependencies between one class/object and another
