I’m trying to use VueJS (Front) + Ruby On Rails 5.x in Backend. I will talk about Rails in some next post… maybe 😆
Why VueJS? well, this project have short scope and like any startup project, must be fast! so, I found Vuetify an amazing library with material directives ready to use. I just has created some Vue component’s, stores and all has been fast since then. The docs is easy to understand and to apply. I just have created the following structure:
Note Templatevuetify.vue component. This is the “common template”. The notifications components is attached to this component for all common messages. All rest it’s same! 😀 you know:
In api folder we have all request to API using the official library for Vue: Axios. These small objects just call to API and return any response. All treatment of exceptions or error handles is allocated in stores. In stores I included the Notifications, so all the components is mainly independent of all request and errors on responses.
All necessary and recurrent data is stored in each ‘store’, so the application don’t need re-call to API for get data. Later of this, all looks very fast and simple to code level.
After use VueJS 2.x I can say that have the magic of AngularJS 1 and some ReactJS concepts, like components. The learning curve is considerably less than AngularJS 1.x and of course of ReactJS, you know… just I needed 2 days with this tutorial and 1 day for apply Vuetify and some customizations.
The most popular questions for Vue is: is Vue scalable for larger apps? I don’t sure 🤔 I mean, how big are we talking about? I guest it works and we keep simple code and fast application. But definitely it’s much better than AngularJS in many respects.
Do you know to Fattoruso musicians family? You should! 😀
I developed a new product for Poker Mavens of Briggsoft Works: MavensManager.
MavensManager is a backend for owners of Poker Rooms with Poker Mavens developed with CakePHP 3.xx (API) and AngularJS (Front End). Jackpot, Rake in realtime, Stats and an Affiliate system are some of the features.
Each user can view all the reports and histories of the game, and get stats for know trends of their business.
There are many ways for lead a development team. Some of them require a work of long term, and other are more practical. The long term is not viable, because the members of a team in this sector is changing constantly.
I know three ways for lead a team that is succesfull if we combine them:
Leader with direct orders This dictatorial way can be used when a project is in crisis, about to fall. In this case the team need a decisive leader and with personality. Also is helpful when must be a make radical changes. Sometimes the members resist to radical changes, or to new labor policies.
If you have member without compromise or enthusiasm you would up the team with this way. But this not good to long term, because some people can be desmotivated.
The coach leader
The coach leader is a technical referent that cooperates with all the team. He take desicions together with all members. Using this method, you should share the knowledge and generate feedback constantly . Each step is explained and discussed with the workteam, empathy and enthusiasm and promoting the personal growth.
The risk of this is the low productivity because the under control.
Working of this mode the leader shows the way, directs the activities and monitors all process but doesn’t participating directly. Supports all their trust in your team. This is useful in teams with high degree of motivation and compromise. In short: direct and delegate.
The great disadvantage of this is that team feel that their leader is not actively part of the team and no commitment as equals.
You must combine this ways, depending of the circumstances. Anyway, be honest, listen of your team, delegate and respect regardless of the technique used, is the most important… for me 🙂
Many times is thought that when starting a new start up project, we must be quick in gather the requirements, quick in development process, quick in test process… etc. We must devote specially attention and time to the requirement process. This step is the more important, and this step is decisive for the success or failure of the project.
I thought some fast tips for starting a new start up project:
Gather information about the customer company:
Objectives, services, products. Is a USP? (Unique Selling Proposition).
Define the targeted audience for the new application (age, social sector, etc).
Access to the application (devices, resolutions, etc)
What likes/dislikes of the other applications.
Define the limit for the plan project: final date, resources
This few points seem fast, but it is a round trip with the customer of many meetings before starting the new project. In each meeting the customer will define new features and flows, and the original idea will mutate.
Mutate a started application can be very difficult, or not viable, for that reason define this points before of start is the best way of avoid the failure.
In software engineering become independent the people of the processes is not an easy task. Even more in start up projects. We can know some methods and practices that we are likely to lead to success, but we are never entirely sure and that’s because every project and every workteam is a world in itself. However, we can always limit to the maximum the errors and failures following simple practices and processes that will help us not to trip over the same stones.
One of the advantages of having trained leaders in the workteams is that we can count on your experience. They will remember cases and situations that led to the triumph of their teams and recognize those practices that led to fail. One of the problems is that in the development market and start up solutions, the workteams are disassembled and technologies and processes become obsolete quickly.
When a challenge arises or a new project appears, the first thing we do is look for documentation about it. Seems that there is always someone who has taken the trouble to share and document information. We have to document in detail our successes and to apply it despite the time, techonologies and workteams. We analyze and write what led us to a happy ending, or failure to learn from it. But also for others who continue to the project, or who entering the team to have everything needed to adapt and continue working -which means cost savings when it comes to bring in a new member-. It’s very common to see people coming and going every day in the development companies, and is more common to see companies lose the control of their projects by this constant employees flow.
When making decisions in a team, forms of work are chosen or agreements are made, is important to write and document a methodical way. All agreed and discussed at each meeting must be captured to take it as reference and guide for our daily work. Is very easy that the words are carried by the wind, and the responsible persons are hidden behind this fact. When the agreement is documented we have a record and evidence that sometimes it helps to keep the wheels on the road.
This documentation of agreements and meetings is also valid for customers, they also must be able to refer to everything discussed and agreed in an easy way and anytime.
How to document start up projects?
The customers want efficient and simple products, but mainly they want it fast and at low cost. Document takes time, therefore increases directly on the cost of the final product. Find the balance between a relatively detailed documentation and the time available to apply is one of the challenges of development of agile applications companies.
There are many methodologies to implement at low cost but in any case it requires a number of practices in the development process and a series of complaints from developers too :). In any case you will need:
An initial documentation to clarify the proccesses of documentation of projects.
A control process that ensures that all member of the teams follow the documentation process.
A quick and easy way to write processes, meetings, agreements, technologies used, way to application and activities taking place.
A tool easy to learn and does not require lot time of maintenance.
This is how a policy of documentation in your workteam will allow you the projects become independent to the people, learn from your mistakes and repeat your success.
Now, as always for closing I leave a new auditory adventure 🙂
Articulate a developer workteam is not should a easy task. Again… in the start up projects all is fast and should be practice for get the final product to customer quickly.
First, we need choose a methodology for organize the work. All the team should know in details all process of work. The way most choosed usually is the Scrum. Why scrum? because es very easy of apply even the dumbest person can work with scrum methodology and not needed many roles. An simplified way of Scrum should be have:
A Product Manager: He has contact with the customer. Manage the available resources. Document their needs and guide to the workteam to the final product.
A Project Manager: Define the scope of the each iteration. Defines the roles and controls the process are complies as: documentation, responsabilities, delivery times, etc.
Testers: He test the quality of each element of the system. Defines the standard and the process of quality. He controls that each part complies with the correct programming methodologies.
Developer team: Generally, all does this. The mentioned roles, they haven’t much time for programming, but usually participate in the developer process.
A system of comunication is essential. Forums, internal messages system (chat), tracker system (fundamental) and a series of regular meetings. The meetings of team is particulary important, this allow to the all team analyzes, shares, talk about the problems or detours and take some decisions together. Any member of the team should can request a meeting for talk about contingences, new ideas or new challenges.
The motivation is the heart of the team. Many enterprises leaving aside this aspect, instead apply more control systems focusing the motivation in the member with the highest roles. But the point is that all the team must be motivated, with energy and especially considering what the customer wants.
This point has become the most sensitive for some development companies. They are dedicating considerable time and resources for obtain motivated teams. Is very common see games rooms, training events, special benefits, extensive and comfortable places of work with high technology in the development companies.
Personally, I think like any worker -in a ideal world- each member of the team must have a competitive salary, be heard and love what do.
In the market of the development of applications for start up business, the estimation of the projects is one of the most crucial tasks. It depends largely the success or failure of all the project. Detours, delays, incidentals and other external factors affect the development time and in the start up world there is not time for a complete planification of project.
However, it’s our duty devote time and effort required for find a way of standardize the estimation process. Why standardize? for reduce the effort whenever a new customer appears. The standardization processes allows invest the effort once.
There are many techniques for the estimation. But, I have some shortcuts for start up projects that usually consider:
Define some available resources:
Size of workteam.
Capacity of the members of team -each member of the team should have a different weighting of the time effort-. For this reason we have take a standard time unit, and weighting each member according to their abilities, e.g. 1 hour for Technical Leader = 1.4 hours for SSr. developer.
Divide the project in small tasks, as small as possible.
Add 5% for testing tasks. Each part must be tested and revised.
Add 2% for documentation of the most important elements.
Add 5% for planification and organization of the workteam (meetings, analysis of the system flow, etc).
Add 10% for contingency and possibles delays.
Once we have define this, we create a small guide for follow each time we have to estimate.