Tag: problem solving

Awesome list of FREE tools Startups should be using

by Muhammad Jawaid Shamshadin TechnologyLeave a Comment on Awesome list of FREE tools Startups should be using

This is a curated list of free tools for everything from productivity to hosting to development tools to designing. These tools are all digital i.e., either app, online service, or downloadable software. Most of them are either free or have limited free option that is enough for startups. Feel free to suggest and contribute to this list.

You can find the original list maintained at GitHub at https://github.com/Ibexoft/awesome-startup-tools-list/.

Tech

Git Repos

Cloud App Hosting:

Static Site Hosting:

DNS, CDN, & SSL:

Site Performance Tools:

Web Scraping Tools

Development IDE/Editors:

Development online platforms/IDEs:

Development Playgrounds

Resource Management Tools

Utilities:

Automated Code Reviews, linting, coding conventions

Testing

Email Service for Developers

Notification (Push, SMS etc) Service for Developers

Changelog

Business, Marketing, Sales, Finance

Idea Validation

Content Management Systems (CMS):

Ecommerce CMS:

Analytics:

Accounting & Finance

CRM:

Team Chat

Customer Support/Live Chat:

Social Media

Sales & Marketing:

Productivity, Management, Organization

Note-taking & Reading:

Project/Task Management:

Attendance, Time Tracking and Management:

Graphics, Design, and Media

Video making:

Stock Photos/Illustrations:

Online Logo:

Designing & Editing:

Laravel: Specified key was too long error on migration

by Muhammad Jawaid Shamshadin MySQL, PHP, Web, Web DevelopmentLeave a Comment on Laravel: Specified key was too long error on migration

When you install a new Laravel project with ‘laravel new’ and run the migration that comes with it you might get the following error:

#php artisan migrate
Migration table created successfully.


 [Illuminate\Database\QueryException]
 SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes (SQL: alter table `users` add unique `users_email_unique`(`email`))

[PDOException]
 SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

To solve this error edit your app/Providers/AppServiceProvider.php file.

Add the namespace:

use Illuminate\Support\Facades\Schema;

and then add the following line in boot() method of your AppServiceProvider class.

use Illuminate\Support\Facades\Schema;

class AppServiceProvider extends ServiceProvider
{
 /**
 * Bootstrap any application services.
 *
 * @return void
 */
 public function boot()
 {
   Schema::defaultStringLength(191);
 } 
}

This should solve your problem. Just delete all the tables and rerun the migration.

Click here to read more about Laravel.

To get better results, change your Approach!

by Muhammad Jawaid Shamshadin Project Management, Technology1 Comment on To get better results, change your Approach!

“If you’re not getting results, change your approach.  The best way to get unstuck is to change your approach.  You learn the most from trying something different.  Sometimes this is uncomfotable, but that’s what growth feels like.” (MSDN Patterns & Practices Blog)

Above quote is from J.D. Meier’s blog and I totally agree with this. I have seen people with different approaches. Some people stick to their habits and don’t want to change the way they are working. Even I have seen people arguing against changing approach and even don’t want to listen that their approach is wrong or there is a need of change in their approach. This is the worst thing that I have seen people doing. People even have to pay off sooner or later but they don’t want change, even after failure. They find different reasons, blaming others or subordinates, or the situation. But they don’t realize that this situation is due to their approach.

Approach is the thing that can lead you to either success or failure. If by adopting one approach you get succeeded, it is not necessary that you will always be succeeded by that approach. With the passage of time and changing situation, you have to change your approach as well. One approach won’t always take you to the top. You have to take different routes, with different approaches, if you want to go up the ladder, otherwise your direction will be downwards.

Overqualified employee is an Asset, don’t lose them

by Muhammad Jawaid Shamshadin Project Management, TechnologyLeave a Comment on Overqualified employee is an Asset, don’t lose them

There is a very nice article Overqualified Employee: A Liability Or An Asset? on Rozee. One point I totally agree with and thought I should post it on my blog. Here is its excerpt…

How To Deal With An Overqualified Employee?

…

Utilize His Expertise

If you have an overqualified employee on the team be sure to utilize his experience rather than feeling threatened by it. His expertise is a valuable asset for you and you can utilize it for the progress of your company.

If you don’t utilize his expertise then he will not be motivated. As author of the article has mentioned here…

Downside Of Hiring An Overqualified Employee:

…

Lack Of Motivation

… the work will not be challenging enough for him and he will get bored quickly, loosing focus and motivation. When an employee loses focus he instantly starts looking for another job and thus becomes a flight risk.

How to improve quality of your standard?

by Muhammad Jawaid Shamshadin Project Management, TechnologyLeave a Comment on How to improve quality of your standard?

Having quality standards for your organization and project is a must. But putting everything in your quality standard can make your quality standard worse. There are few guidelines you can consider when making a quality standard, but following two are most important I think.

  • Develop a consequence for each quality standard. I like to call this the “Who cares?” test. For each standard you identify, develop a logical, thoughtful consequence that will occur if it is not met. If you and your advisory board can’t identify a realistic outcome, or if the consequence is minor, consider revising or deleting the standard. It’s too easy to throw everything into your quality standards list. More is not always better, so be sure to focus on what matters most.
  • Evaluate the quality standards as a regular part of your project postmortem. Putting practical standards in place is a great first step toward meeting the expectations. So, to ensure that your quality standards continue to pay dividends, it’s important to include a regular postmortem review. Ask questions such as:
    • Were any quality standards ignored? If so, was the consequence significant?
    • Was the product designed with the quality standards in mind, or were they applied after the product was designed and needed to be tested?
    • Did the team take the quality standards seriously, or did they follow the guidelines because they had to?
  • Getting a good read on how project teams viewed the quality standards will help you improve these measures, and over time they will evolve with your organization.

    • There is a good article on Microsoft Office Online providing bit more guidelines on developing a good quality standard and then maintaining the quality of your quality standard 🙂

    How change can bring motivation?

    by Muhammad Jawaid Shamshadin Project Management, TechnologyLeave a Comment on How change can bring motivation?

    I always believed that bringing change is one of the key factors which develops people’s interest and keep them motivated. But I was surprised to see that how promoting another person in team can motivate others, specially where situation is worse and people are fed up. Bringing change can charge people up, but we have to see that what type of change is necessary. Sometimes a change can demoralize people, specially when people are already happy with something.

    Another factor to keep your team motivated is to communicate with them and ask their problems, and try to solve it. Again, solving problem will bring change and your team will become more responsible, honest, and motivated.

    How to kill your time by hardcoding?

    by Muhammad Jawaid Shamshadin C/C++, C#, PHP, Project Management, Technology, Web DevelopmentLeave a Comment on How to kill your time by hardcoding?

    My colleague asked me to help him solve an issue he was facing. I sat with him and after spending more than half an hour I realized that someone has hardcoded the server name :@ while we were assuming that we have already moved to another server.

    The main thing to realize here is that if we have spent few more minutes in making the server name configurable at first place then we could have saved hours that we spent later just to find out that server name was hard-coded. Not doing this results in frustration, waste of time, de-motivation, brings down the moral of the team, and finally kills productivity and you lose credibility.

    Hidden Reasons for slipping project deadlines

    by Muhammad Jawaid Shamshadin Project Management, TechnologyLeave a Comment on Hidden Reasons for slipping project deadlines

    There can be so many factors that affects the deadline and project can be delayed. There is an excellent article 10 ways to get a slipping project back on track on TechRepublic explaining the remedies. But in my opinion tips given by the author are where there are already processes defined and a proper organizational hierarchy is maintained, not just maintained but also everyone at its position has its role and responsibilities defined and he works according to his role. At least to some extent. But what when this is not the situation? Let me explain here by first commenting on the TechRepublic post.

    Overtime was on the top in that post. Author has already accepted that this is an option when you are at the end of the project, and there are better strategies if you are in early stages of project. I agree with that. You cannot work overtime for a long period. Few overtimes are acceptable. I just wanted to mention this here.

    Few other reasons of slipping the project deadline is setting the deadlines blindly, assuming ideal situation and not keeping the buffer, specially when there is a learning curve when you are working on something new.

    Another problem is that if there are lots of senior guys and everyone is imposing his own decisions discarding other’s. Having senior guys is good but everyone should have separate responsibilities and no one should interfere with other. Discussing matters, coordination, and giving opinion is something else. Not having this leads to unstability.

    Another major big problem is with the management when talking in terms of investment. Besides company’s plans few things are obvious where anyone can see that investment has been done at wrong place or investment is not done where it was supposed to be. Like hiring skilled people and paying them good. Finding cheap human resource does not always work. You should know when you have to invest in human resource and when not. And if you already have good human resource then appraise them before you loose a good resource and someone else steals it from you. Keep in mind as long an employee works for a company, he becomes more valuable asset since he has learned so many things and new employee will take time to learn those things. If you can understand this then you already know that time is money. And if employee leaves in the middle of a project, then obviously there is a big chance of slipping the deadline. You have to put extra resource, reschedule accordingly, assign resource etc etc.

    Another one is related to human resource and team. One should have experts and should have responsibilities and roles defined. Don’t expect one to do everything from project management, to design and architecting, to learning, to implementation, to support. Project Manager is one guy, System Architect is another, Developer is another, Designer is another, Tester is another, Network or System Admin is another (sometimes two), and Support personal is one another. If you don’t have enough money to hire all these people then don’t jump into the big business, otherwise you will fail. Start with small and gradually build your team. This is a long term investment.

    Besides human resource, other resources are also important, including facilities. Not providing sufficient resources to the team wastes time and at the end deadlines are slipped. Employees also get frustrated. Even a very small resource or facility has its effect. Not upgrading systems, network issues, not providing healthy environment, and even not having standards and policies are the reasons. Having flexibility is something else and not having proper company policies is something else. Not having these demotivates employees and one cannot give his 100% then.

    One another important thing is forecasting and future planning. If you don’t have the plan and has approach like we’ll see when that will happen, then don’t be surprised if you fail to accomplish your goals.

    When working on projects you should have dedicated resources, not the ones that come on and off. I am typically talking about human resources here. Since working on project and to complete it in time needs concentration and focus. There can be resources who come on and off but don’t assign them critical tasks. Use them for assistance only.

    Processes! Just having separate development and testing teams doesn’t mean you are following processes. There are processes for within individual teams as well. If processes are not defined then this is also a reason for not meeting the deadlines.

    Besides all this I also recommend reading Peter Steven’s blog post 10 Ways to Save a Slipping Project.

    Threads in Perl without using thread module

    by Muhammad Jawaid Shamshadin Linux, Technology1 Comment on Threads in Perl without using thread module

    Threads are not good in Perl. If you want to know why, you can read PerlMonks article here. But C/C++ threads are good 🙂 How can you leverage the benefit of C/C++ threads in Perl? Well, if you have a C/C++ library which is multi-threaded then you can write a Perl wrapper on C/C++ library. For writing a wrapper you can use Inline::C or Inline::CPP module, that provides a very gentle and easy way to wrap up your C/C++ calls.

    What happens is that if you call a C/C++ function which uses threads from a Perl script/process, it will make your Perl process multi-threaded. You can see this by using -m option of ps if you are on Linux platform.

    I was working on a Perl based project and I used a multi-threaded C/C++ library. I was curious how will it work. I ran the Perl process and when I see the process in ps with -m option, it was showing two processes, actually one process and second was the thread. When I was using a single threaded library it used to show only a single process in ps. I also tested the functionality which was supposed to use the multiple threads and it worked as expected.

    I think this is a better way to use threads in Perl if you really need threads, instead of using thread module of Perl. If you are not desperate, then try to stick with single threaded model of Perl, or use Perl wrapper over C/C++ multi-threaded library.

    Why code bad instead of clean code?

    by Muhammad Jawaid Shamshadin C/C++, PHP, Project Management, TechnologyLeave a Comment on Why code bad instead of clean code?

    I was reading the book Clean Code – A Handbook of Agile Software Craftsmanship, Rober C. Martin Series. A section in chapter one caught my attention and remind me of code and reasons that I got for writing bad code and designing bad solution. Now I think this is a good argument against it which I am quoting here from the book.

    “Have you ever waded through a mess so grave that it took weeks to do what should have taken hours? Have you seen what should have been a one-line change, made instead in hundreds of different modules? These symptoms are all too common. Why does this happen to code? Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right.
    We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.
    This may be a bitter pill to swallow. How could this mess be our fault? What about the requirements? What about the schedule? What about the stupid managers and the useless marketing types? Don’t they bear some of the blame?
    No. The managers and marketers look to us for the information they need to make promises and commitments; and even when they don’t look to us, we should not be shy about telling them what we think. The users look to us to validate the way the requirements
    will fit into the system. The project managers look to us to help work out the schedule. We are deeply complicit in the planning of the project and share a great deal of the responsibility for any failures; especially if those failures have to do with bad code! “But wait!” you say. “If I don’t do what my manager says, I’ll be fired.” Probably not. Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.
    To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly and-washing in preparation for surgery because it was taking too much time?2 Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.
    So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.”