Brian Burress

Campbell Ritchie wrote:How much of a market do you think there would be for such books in Spanish, etc?

That's a good question.  I've not looked into any market research on the it.  Quick google on the populations - there are around 2 billion native English speaking people vs 437 million native Spanish speaking people.  Native Spanish speakers are roughly 25% of the English speakers, so the market potential could be about 25% of the English sales potential?  I understand a deeper analysis of age ranges, etc would make this a better guess. Maybe someone on this forum will have more accurate insight!

Aimee,

Congrats on having the book published.

Great concept to get kids, especially girls, interested in coding if not ultimately tech overall.

It looks like the book is only available in English.  Have you looked into having the book translated into other languages such as Spanish?  

It seems many kids in other countries are being taught English and that for the moment English is recognized as a universal business language.  Even so, there might be a better opportunity to connect with the targeted age range if able to read in their native language.  I work with an organization which performs outreach/mission trips in Spanish speaking countries and one of their goals is to help keep the kids in school to get an education to be better positioned to get a job, support a family, etc.  One of the aspects they are trying to tackle is to get more technical exposure to the kids.  A book such as yours may help foster interest on the part of the kids.

Thank you!

I have only read up on Xamarin at this point and not actually developed an App.  The biggest benefit that I have seen is that you can develop one application which can be compiled and delivered to both Android and IOS.  There are hooks available to implement customization for either platform as needed.  I understand that some functionality can be implemented in a way that it is rendered "normally" in the target OS (i.e. the user experience of IPhone vs Android is a little different and Xamarin handles some situations for you!)  To me, this is the "why" you should use Xamarin over native development which requires you to build/maintain two code bases.

I am very curious to understand who the target audience is for the book!

Welcome Jim!

A timely book as I just made a suggestion to a CEO of a startup a couple of days ago to look into Xamarin as they are developing native for IOS and Android and concerned about time needed to support both platforms.

I have experimented with mobile development a few times and what I have struggled with most is testing.  Specifically, I have found the android simulator to be slow, clunky and mysterious to get to work consistently.

I see the chapter covering Xamarin UITest.  Does this tool work with the simulator or is this a separate (and more reliable?) tool for testing?  What testing beyond UITest have you found useful?


Who is this book geared toward?  I have 15 years or so of experience using Java/C#, mostly backend and middleware development along with HTML/Javascript.  From glancing at the contents, it appears this could be the proper book to get me over the hump and be able to turn out some apps.

Thank you!
Brian

Welcome Julien!

I skimmed the contents and summary and it looks like the book covers what I will call "traditional" security concerns (server security, protecting the data from outside access, etc) which in and of itself continues to get more and more attention in the industry.

I think the DevOps concept opens itself up to an additional aspect of security which pertains to regulatory and compliance issues surrounding data.  In addition to US laws, many states have laws pertaining to data and security, there are HIPPA considerations for health care verticals, and regulations such as the EU GDPR which impact companies with an international customer base.

This lends itself to situations where a company needs to control who has access to the data and possibly even logging the access of that data.  While working as a 'standard developer' for a major US financial institution, we had to work through regulatory issues such that the same person could not be in charge of development and deployment, could not access test systems/data as well as production systems/data, etc.

For lack of an eloquent way to put it, this starts to "gum up" the concepts of DevOps.  

Does the book address anything from this perspective?  

If not, maybe there's an idea for Volume II  ;)

Welcome Richard!

I see a couple of sections in the book for security; however, neither appear to cover my question of best practices to architect user security.

Considering figures 1.5 and 1.7 in the book, what sort of approaches do you see for implementing that also maintain these micro services as separate entities?  To provide for proper authentication/authorization there either needs to be a controller of some sort sitting in front of all service calls before routed or the security needs to be built into each micro service.  The former approach seems to water down the benefits of micro services, especially considering the automated concepts of AWS/beanstalk.  The latter seems to erode the benefit of service independence as the security model needs to be implemented in each service up to and including a tie in to the persisted security.

Granted that some service implementations can be security agnostic.  In the context of the book and the micro blogging site example, as well as many real world applications user level security is needed.

Are there other angles I am not considering?

Thank you!

I may be overlooking something in the outline, but it looks like this is "just" a computer programming book. I don't say "just" to insult you by any means, but more the result of observing the word "Scientist" in the title and an having expectation to see something more than programming.

I think IT folks, and likely folks outside of IT, lack the scientific skills needed to be successful. First and foremost, there is a lack of problem solving skills. Many IT people I have worked with have great technical skills as long as you tell them what to do and solve the problems for them. Beyond that, I see a lacking of analytical skills and what I'll call a lack of "Scientific Investigation" skills. If you consider that to create solid solutions a programmer should be very methodical when reviewing requirements, create test plans, and writing tests, etc then it seems to parallel following a rigid procedures of a scientific investigation.

Again, if I am overlooking coverage on this topic in the book, my apologies & please point it out. Assuming that I have not too quickly scanned the book, please consider the possibilities of writing/coaching for a "Scientist" and share any thoughts you have on it here.

Campbell Ritchie wrote: But how are you going to know whether the code you sought and found is A+ gold standard code or total rubbish? .

I was more in the mindset of syntax and construct aspects of using a language and coding (i.e. creating code not copying existing code). If you are copying code from any source then you do need to be able to assess and understand what it does or have a strong process for vetting/testing is, so point taken and I agree with you strongly on that point as well.

A lot of the questions I see, especially certification exam like questions, are more memorization vs actually testing a person's programming skill.

Couple this with the ability to Google proper syntax & classes and I think it is more important to be able to ask questions that identify the coding ability in general without getting into a bunch of specific detail. I had memorized all of the information needed to pass the Java Programmer Exam, Web Component Developer Exam and the Business Component Developer exam. I have since forgotten most of the detail as I don't use it on a daily basis.

Fast forward to my current job which is primarily using .Net C# (for the past three years). I have high level knowledge of the basics of C# but tend to Google when I need to do something. After 25+ years of programming I tend to think about what needs to be done abstractly and then figure out the language construct later.

As we continue to see more an more languages created, it would seem more important to find developers who have this abstract understanding and will morph through the languages as they continue to evolve.

Feel free to agree or disagree with my perspective above. I mainly wanted to state it as background for my question. How does the book address what I will refer to as abstract questioning as well as questioning that isn't merely yes/no? More open questions that allow the interviewee to give an answer and embellish on factors that cause them to think that way can be far more revealing than some specific syntax question.

A Flatoff wrote:The bigger problem is that there may be easier / better way to solve the user's business problem, but because the business problem is unknown, the better solution may not be realized.

I have experienced this as well. Sometimes the solution built is what the customer asked for and not what they needed because the developer was merely "an order taker" as opposed to someone engaged in learning a little about the business and about the problem being solved.

Referencing the bullet points of the book, it looks like a lot of the focus is on the developer - determining what needs to be done, documenting what needs to be done, writing tests to validate the work is properly done, etc. These are all important points.

Does the book also address how to educate the customer about what software development is, how it works, the terminology, what it means to approve requirements, what a change control process is, etc? From my experiences, there are many cases where the customer is so far removed from the technology and development processes that they don't understand how their action or inaction impacts a project. Agile attempts to address this some by having a business person "embedded" on the team to give approvals, make quick decisions and such but I don't see that addressing the problem entirely.

Good topic for a book, by the way. Technical skills are obvious needs for a developer. This topic, and topics covered in the "Soft Skills" book by John Somez are things that developers lack which can help bridge the gap with customer communications.

A similar question has been asked, but I'll make it a little broader - who is the target audience for this book?

Based on the bullet points, there are the points about "bosses" which imply the reader is a run-of-the-mill developer and other points about building a time tracking DB and getting properly paid for time which imply the reader is more of a consultant and even more specifically the owner of the consulting company.

Proper requirements gathering and documentation all important in all of these scenarios but some of those bullets seem far off from "Customer Requirements" and seem more for someone who would be focused on working as an independent consultant. As I type this, I am wondering if the title may even be too narrow as the topics are more "how to succeed with your software consulting business".

Hello & Welcome,

I have "old school" experience with message systems (I worked with MQ Series before it was renamed to Websphere/MQ--> IBM MQ) as a bridge from web applications to mainframes. I have also built a reference implementation using JMS and reviewed SonicMQ and RabbitMQ and feel that all of these messaging systems are pretty similar. I won't say that you know one and know them all, but the concepts and use are similar.

1) Do you think this book would be an appropriate starting point for someone with messaging system background with something other than RabbitMQ?

2) What do you feel your book offers for someone who already has background with other messaging systems?

3) Have you worked with other messaging systems? If so, do you agree or disagree with my feelings on "similarity" with respect to RabbitMQ? If you disagree, please point out some things you see that are exceptionally different as I may have glossed over something.

Thank you!

Welcome Nicolas!

What sets your book apart from other Application Design books?

How will your book benefit a seasoned developer (ex: java, c, c#, etc) who already has strong design skills?

Are there elements which you feel are unique to JavaScript?

Thank you!
Brian

I think madhuri touches on it but I think soft skills goes far beyond just working harmoniously with other people.

It may help to define what "hard skills" are. I see hard skills as the skills you have specifically related to or required for your job. The language(s) you code with, the operating system(s) you work with, the programming styles (i.e. object oriented), etc are examples of hard skills. They are trainable/learnable skills.

What are some things missing from actual skills and abilities required for a job? To me, those are the soft skills. Aptitude, attitude, communication abilities, personality, and work ethic are all soft skills at least for a developer. With the exception of certain communication abilities, these things are generally not trainable. Someone with the right aptitude can learn a new programming language; however, everyone does not have the aptitude to learn a new language. We may be able to teach someone a new communication hard skill, such as English or French, but that will not give them the soft skill of being able to use that skill to effectively communicate with people. I am a little dramatic in stating soft skills are not trainable as some aspects like work ethic and attitude can be changed/controlled by a person -- I think you can see the perspective vs a skill like coding.

I have had the opportunity to be the interviewer on many occasions for a variety of positions. In addition to a certain amount of hard skills, I have learned to look for the soft skills in candidates. The soft skills are the things that are part of who that person is and least likely to change. I'll take my chances letting an intelligent java developer learn C# as opposed to taking mt chances that someone who can't speak clearly is going to learn to speak clearly by attending conference calls.