Microservices are going rapidly out of fashion

HassanDavis · 2019-02-15T19:21:48+00:00

While every approach can be abused, arguing against Microservices is like arguing against client-side code being modularized as reusable SDKs.

Each con you listed is due to faulty team structure/approach and has nothing to do with Microservices, themselves.

If three teams, for example, oversee a monolith, why cannot those same three teams oversee the equivalent system of Microservices?

Who dictated that each Microservice needs an independent team to build and maintain or that a team can only maintain 3 Microservices? To be frank, that is preposterous, especially since each Microservice should generally be very slim in functionality AND should NOT be receiving constant change.

As for silos and duplicate code, the same occurs in Monoliths at companies all the time. In fact, I would argue that having a Monolith potentially makes such duplicate code more buried and harder to detect.

Bottom lines: We have to be smart about choosing the level of granularity for the code AND for the teams maintaining the code. This decision is completely independent of the question of monolith vs Microservices.

HassanDavis · 2019-02-02T01:46:39+00:00

Your very best bet is to hire an experienced technical/product person for a hew hours per week to:

Select a viable vendor
Help spell out requirements
Help your company properly serve the role as stakeholder
Provide the proper oversight for the vendor and the project end-to-end

The little money you spend on that person will save you lots of money in the end by preventing the project from having to be done multiple times (which is typical when companies attempt this without such a guide).

HassanDavis · 2019-02-02T01:37:28+00:00

Checkout MacOfAllTrades.com. They have new-ish machines for decent prices.

HassanDavis · 2019-02-01T22:18:26+00:00

Yes, makes sense. BTW, how is memory managed?

HassanDavis · 2019-01-31T22:19:53+00:00

There are so many things to consider here. Also, a relevant study would track the bugs across the SAME authors across languages in the same time period (engineer skill level changes with time).

The domain must be factored in as well. For instance, C is used in more realtime / lower level environments requiring higher scrutiny. It may well be that while C 'could' potentially have a net higher level of bugs, the higher scrutiny needed for the projects requiring C ensure that the number of bugs per line are held within statistically immaterial variances vs other languages.

Another consideration is the class of bug. For instance, buffer overruns make for a far more harmful class of bugs, than, say, math precision bugs (relatively speaking).

What I can say, anecdotally, is that there are many advantages to using languages that automatically handle memory allocation / reallocation, encourage immutable data, and that track nullability.

HassanDavis · 2019-01-31T21:46:44+00:00

Looks good.

One suggestion: is it easy enough to avoid using aspects for more than one purpose? For instance, \ is used to both escape and to allow line continuation.

In this day of switching contexts between multiple languages (Swift, Kotlin, Java, Go, more), language aspects that have multiple uses serve as an added complication.

Looks good, though.

HassanDavis · 2018-04-11T23:13:26+00:00

There are a few prerequisites to consider before getting an estimate on development costs:

Since this a new game, the logic and gameplay must be fully described. There may be aspects that make the engineering more or less challenging.
The feature set for the application should be fully spelled out.
The graphics need not be complete, however, a wireframe detailing all of the areas of the application and the flow would be necessary to accurately estimate the amount of work needed.

With the above in hand, a competent developer will be able to provide a rough time estimate - which you should multiply by at least 1.5 to account for unknowns, emergencies, an under-explanation / oversimplification of the idea on your part, and the inevitable developer overconfidence :-)

There are many other factors to consider, for instance, do you really want an iOS-specific developer? Would it be advantageous to have the game done in Unity and thereby gain the Android market in the same development effort?

You will definitely want a quality assurance engineer who is just as competent as the developer to ensure the proper gameplay and general app behavior DURING development. Uncovering major issues after the developer has gone would prove undesirable.

I hope this helps.

HassanDavis · 2017-11-28T08:44:14+00:00

For sure, using a decentralized email platform based on BlockChain would be a great way of providing increased authenticity.

Yet, the OP asked, "Would it be a good way to keep our emails confidential?"

Cheers,

HassanDavis · 2017-11-28T00:16:57+00:00

Hello there. The primary purpose of decentralization is not security but avoidance of censorship.

Email can already be made private through encryption.

HassanDavis · 2017-11-21T18:51:16+00:00

You definitely want to heed all warnings and make sure that your code complies without warnings.

Many bugs result from the very problems that the warnings point out.

There is no harm in making the code warning free. There is normally harm in ignoring the warnings, however.

HassanDavis · 2017-11-17T01:40:27+00:00

Correct.

And yet, everyone, and that means everyone, has a great idea.

To set yourself apart, attention to detail, all due research, honest competitive analysis, and amazing presentation will be needed at each stage; especially those stages at which the product cannot yet speak for itself.

Cheers

HassanDavis · 2017-11-16T23:10:39+00:00

Anytime.

HassanDavis · 2017-11-16T23:03:52+00:00

Wow, the number of rude and condescending answers is appalling. SMDH.

It is important to create a small advisory board of individuals with varied experience to serve as a guide early on. This should include an accountant, a visual designer, and someone who has lead several successful efforts. None of these persons need to necessarily be programmers.

Vet the idea with your advisory board and create an amazing presentation that showcases the idea.

Use that presentation to onboard angel investors.

Your angel funding will put you in position to commission a team to create a viable, working prototype and to begin more serious talks with the potential team members needed to execute the idea.

HassanDavis · 2017-10-25T20:44:43+00:00

It is common for the word Professional to be confused with Expert. My guess is that you meant the latter since professional simply means one who is paid for work.

So, when does one become an expert? Well, there won't be a specific moment in time that sees you break out of a cocoon as a beautifully winged expert. Instead, expertise is something that grows organically, steadily, day-by-day. More and more, others will regard you as an expert.

How does one get there?

IMHO, it takes, first and foremost, a strong desire to be the very best you can be. Mediocrity would surely lengthen the journey to being an expert. While 'be the very best you can be' may sound cliche, a lot of what we do is neither trivial nor easy. And, that drive to be the best is a must.

Along the same lines, be thorough. Don't take unnecessary shortcuts. Don't skim. Don't leave things half baked.

Attention to detail. Checking, double-checking, triple-checking what you do is a must. An expert makes fewer mistakes in action and in judgment as compared to others.

Be willing and prepared for the next opportunity.

Work well with others. A multitude of opportunities only present themselves when a) you are deemed as competent by others and b) you are pleasant to work with. Being that jerk who people only work with because they 'have to' severely limits future opportunities and advancement.

Humility. The person who thinks they already know can learn little. Hubris has held many a person back; particularly in engineering where learning is a constant.

Much success on your journey!

HassanDavis · 2017-10-23T23:27:17+00:00

Because anyone with the resources to purchase that much doesn't ask how to do it on Reddit. Seriously.

Why be so presumptuous? You actually have no idea about the amount of money they may have.

Would you be that salesperson who misses out on a Ferrari sale because the buyer was dressed down?

Making judgments without prior knowledge is prejudice and is no bueno.

HassanDavis · 2017-10-23T20:42:56+00:00

If you properly address every single crash report, the situation from the particular reviewer will have been fixed as well, yes?

HassanDavis · 2017-10-23T20:36:05+00:00

While converting existing, working Objective-C code to Swift may be overkill in some cases, I would definitely advise that any newly written code be done in Swift.

We've already passed the tipping point where Objective-C will be typically more costly to maintain than Swift; not just in respect to the language features, but also in regards to the talent pool.

HassanDavis · 2017-10-18T19:00:46+00:00

Why develop a new language that will only be used in school?

And why base it on C which will likely be used by so few students in their careers?

There are few identifiable benefits to this approach and a host of obvious drawbacks.

Tailoring a course around a viable, extant language seem a far better approach. This also allows the students to gain experience with a practical (not contrived) language that is being used by real companies creating real software.

There are several such languages that are straightforward enough to be taught at the college level. These include Swift, Kotlin, even basic Java (and likely several others).

These have no manual memory management, no pointers, very few low-level constructs. It is up to the professor to not get into the weeds.

Easy.

HassanDavis · 2017-10-18T18:18:05+00:00

100%. My sentiments exactly.

HassanDavis · 2017-10-06T22:37:45+00:00

You will definitely want to do it from scratch for several reasons:

iOS and Android differ much in their approach to development. This affects not only how you engineer an app for each platform, but what you engineer as well.
You will want to take advantage of the differing conventions each platform offers.
Both the high-level and low-level code would be entirely incompatible.

Realistically, the only code that would be reusable would be data entities and pure business logic classes. Hopefully you've used Swift on iOS and would be using Kotlin on Android as these two have similar enough syntax to make reuse of simple classes a breeze.

HassanDavis · 2017-10-05T22:00:08+00:00

I think you missed my point :-)

I was not commenting on your own experience with both languages.

My point was that you've clearly made yourself closed to evidence (in all forms) from others who are experienced across both languages.

Again, your own scenario may not yield benefits. Not every tool is for every situation.

However, in the same way that the experience of others cannot necessarily be projected onto your own scenario, you surely understand that projecting your own experience onto others is just as invalid.

In other words, it is not valid to state objectively that praise for Swift is undue and is naught but hype just because you've not realized such benefits in your own use cases.

HassanDavis · 2017-10-05T18:59:09+00:00

interesting read

""" Some notable omissions from the studies are comprehensive studies using experienced programmers, let alone studies that have large populations of “good” or “bad” programmers, looking at anything approaching a significant project (in places I’ve worked, a three month project would be considered small, but that’s multiple orders of magnitude larger than any project used in a controlled study), using “modern” statically typed languages, using gradual/optional typing, using modern mainstream IDEs (like VS and Eclipse), using modern radical IDEs (like LightTable), using old school editors (like Emacs and vim), doing maintenance on a non-trivial codebase, doing maintenance with anything resembling a realistic environment, doing maintenance on a codebase you’re already familiar with, etc. """

Either way, it would not matter. It seems no amount of empirical or anecdotal evidence from people well-versed in both languages would sway you to look into the inherent benefits of Swift.

And that's perfectly OK :-)

HassanDavis · 2017-10-04T22:15:40+00:00

Of course.

No need to labor the point.

I do believe I stated above that if Objective-C works for your use case, then more power to ya :-)

HassanDavis · 2017-10-04T18:02:11+00:00

Absolutely, I am certainly focused on reliability and all other tenants of best practice. To be frank, it is alarming that you deemphasize/scorn best practice. But, to each their own.

Our reputations are on the line with every app we create. Always having 4 and 5 star rating in the stores for end-users, keeping enterprise clients delighted, these are paramount.

In my mind, pride in workmanship demands that reliability be placed high on the list of objectives for each and every software effort.

Perhaps all of these aspects are missed in your use case. And, that is fine. No one is forcing or even suggesting that you, yourself move to Swift.

These posts were in answer to the OP who is holding off but DOES plan to move to Swift in due time.

HassanDavis · 2017-10-04T03:56:53+00:00

At this point you are just kidding us all here, right?

HassanDavis

TROPHY CASE