Plesk and cPanel are well known commercial control panels that provide a graphical interface to simplify the process of managing a Linux web server. But I don't want to use them because for my use they are overkill: I don't need a general purpose hosting reselling panel.
In my opinion, they are also too bloated and taking over too much control. But at the other hand, I find it convenient for example to create a domain or a database through a web interface without having to login to the shell.
There are also relatively reliable and proven Open Source alternatives like Ispconfig or Webmin. But I was searching for something more visually attractive and modern-looking.
I admit that it's maybe superficial. But the outdated interface design often reflects the archaic legacy code base behind it.
So I began to search for a fresh and elegant new control panel. Wikipedia has a nice comparison of web hosting control panels and after some searching, I had a short list of 3 potential candidates: Froxlor, Ajenti and Vesta. They all have a clean and uncluttered interface. Their code is Open Source and accessible at Github. They met the main criteria that I found important. But I had to install them and experiment a little before I could decide which one to use.
Organizations change processes (with really good intentions) to fix a problem only to discover that their change has created a second problem, worse than the first. These secondary problems are known as unintended negative consequences. There are many humorous and serious examples.
Survival of the fittest for organizations is about adaptability to the evolving business conditions and corresponding new realities. Change is thus inevitable.
The snake which cannot cast its skin has to die. As well the minds which are prevented from changing their opinions; they cease to be mind. ― Friedrich Nietzsche
But change is not easy and sometimes even very dangerous. The delicate equilibrium state that an organization has established does not happen overnight or without profound reasons. Therefore a rigorous change to achieve a local optimization can worsen the overall organizational output immensely.
“Good, fast, cheap: pick any two” is an often heard project management statement. It is a trilemma from the classic management triangle. The joke is often used to subtly figuring out the budget, deadlines and the requirements.
A Venn diagram does perfectly visualise project limitations and makes it very understandable and logical.
Although this conceptual model helps us think about the project constraints, logically it is not very solid.
There are lots of ways to develop software. From the "cowboy coding" that involves no design, no documentation, and no testing to strict and rigorous processes. Almost all software development standards describe how to perform and improve specifications, designs, coding, and testing.
The end goal of all software development processes are: creating software that works as intended, is on time, within budget and can be maintained. But which development approach is the best?
Is this context-dependent or are there any generic aspects so that an overarching software development "framework" can be labeled as "best practice" for the status quo?
At the beginning of a new to start project, I get the question how to set up the project organization. I try always to answer it shortly:
The project organization must consist of as few people as possible and only dedicated people that will really contribute to the project and has interests that the project will succeed.
It is a loaded answer with a lot of criteria and questions in it. It can be helpfull to explain the underlying reasoning.
I work now for 1 month on an assignment for Minoto Video. It is a SaaS platform for video that can be used for easily placing video's on a website or to integrate it within an application by using the API. The goal is to be something like Heroku for video implementations.
In the short period I am working here, I have learned some things that I am going to sum up so I can reflect later on.
There are many reasons for fallacies, many arise from oversimplification and others from urban myths. I have listed the most common and harmful ones.
The key to success is the ability to adapt to the changes that the new media brings. There is not much to gain by either resisting or denying it.
Internet has its own rules and influence. As a result, more and more people are forced to make sense of it. But it doesn't work the other way around.
If you want to order a pizza and don’t want just one of the regular pizza’s on the menu, you can of course build your own pizza. At that moment, things will get really complicated. If you just choose a couple of toppings, it is likely that your pizza is not special at all: It’s just a variation on one of the pizzas on the menu. Then you get aware that actually someone profoundly thought about the pizza’s on the menu and configured the pizza’s really in a smart and logical way already.
Pizza syndrome is a metaphor that I use to describe the phenomenon when you want to “order” an extraordinary web product.
But if you insist to not order a regular pizza, one thing you can do is add a lot of toppings on your pizza. It is a sure way that your pizza is really unique and one-off. At the other hand, you are also sure that it is uneatable. It is not tasteful to add anchovies, salmon and shrimps combined with brie, bacon, chicken and spinach.
Agilists are not to be divided into divisions or sections but rather be united under one manifesto. Common purpose is off course the same: uncovering better ways of developing. However, since the publication of the agile manifesto, there have arisen distinctions into schools of thought, methods, traditions, and related practices. Furthermore, the same organic and natural emergence of fragmentation happens also with Scrum.
Since the publication of the agile manifesto, there have arisen distinctions into schools of thought, methods, traditions, and related practices.
While implementing Scrum in an organisation, there is always a discussion about the implementation of rules and the level of flexibility. Some practitioners argue that all best practices must be followed as literally as possible and that it is otherwise not Scrum. Other practitioners argue that the essence is important and that the practices are all up to individuals to follow, change or set aside. While the description of a practice can be very clear, the implementation in practice may still differ from team to team. Like a religion we can say that there are interpretation and perception differences caused by the context.
It strikes me that web development projects often do not learn enough from the past experiences in other fields. One of these problems lies in the area of (new) product development. Most web development projects have not enough emphasis on product management. While agile development practices heavily encourage to "take action", they are off course not against substantial thinking about the product. To stress the importance of a well thought out product road map, Scrum tries to constrain it by saying "A sprint should only begin if the product backlog is prioritized and ready".
Web development projects have not enough emphasis on product management.
But Scrum doesn't give you product management tools because Scrum is not a silver bullet. It is just a framework for completing complex projects. Scrum is not a market research method or a tool for generating new business ideas. It is said so many times but maybe not often enough, because I hear still people talking about Scrum if it is a silver bullet. Scrum is neither a substitute for skilled and experienced developers who write good code or solid engineering practices.
The origin of Scrum lies in software engineering where visual appeal didn't really matter. When we mention software design, most people will think about the technical design and not the visual look of the software. On the other hand, website development is a lot about visual communication. Therefor when we mention website design, most people will in contrast think about the visual aspects.
When we mention website design, most people will in contrast think about the visual aspects.
Here lies the challenge when Scrum is applied at website development. A product backlog is not seen sufficient when the product owners want to describe the visual communication requirements. As a solution, they want graphic designers to design the website upfront. But this complicate things even more, because a graphic design implicitly requires functional solutions. They fall unconsciously in to the trap of "Big Design Up Front".
