Apple Blows it Again 16GB and a Touch-me Bar - Yippee

6-5-2017
Ditto...


10-27-2016
I was amazed at what I could do with my MacBook Pro back in 2012.  Being able to run Windows and OS X at the same time, on the same laptop, allowed me to code the services that went with my mobile apps.

When I need to do heavy server work I carry around my Alienware which has 32 GB of RAM.  I have added new parts to it as they came out, but it did not survive the Windows 10 Anniversary update.   I have been eyeing up a couple different 64 GB devices to replace it, but was holding off for the new MacBook Pro.

There is no way I thought they would keep it stuck in the stone age with only 16 GB.  Apple will not let us run their OS on a real laptop, but they themselves won't build us a real laptop.  I am not really sure what they are thinking, but not giving us anywhere to develop is just sad and sickening at the same time.

They should give all refunds on out developer licenses which I just renewed.  Apparently for no good reason at all.

It blows my mind that we waited this long to get a toy laptop with a little bar that you can touch.  Thank goodness it is thinner.  They will be able to store more in the warehouses where they will be sitting.

What is up with the stupid thinner thing anyway.  Give me a 17" screen, thick body that has some awesome cooling fans for my 64 GB of RAM.

So my choices are …. An awesome laptop running Windows 10 - which does not run, or a toy MacBook with a stupid touch-me bar.  Yippee…. I never thought I would want to retire, but with the way the IT industry is going, you'd have to be nuts to want to be part of it.

O that's right….  I have my iPad Pro that I can program Playgrounds on…. I'll just use that!!!!

The Ransomware that was once the worst PC Virus/Trojan in history - Windows 8 now called Windows 10

This virus that was once known as Windows 8 and 8.1, that has been renamed Windows 10, has been allowed to go unchecked by both the business world and the government.

It masks itself as an operating system, but as soon as it has been installed it kicks off an unstoppable process called Windows Update.  It reaches out and pulls down more and more of the virus creating a deadly package, which will shred your systems mercilessly.  That is unless you pay the hackers.

The hackers who created the ransomware, known only as Microsoft, have lobbied Washington and held some of the biggest businesses in the world hostage.

We have suffered repeatedly from the "Windows 8 and 10 Windows Update Restart Trojan", but the latest took us down completely.

We have recently suffered the dreaded "Windows 10 Anniversary Update Bomb - Spinning Login Circles".  It has destroyed my Alienware 18X.  Although the data was left behind, 5 years worth of software configuration, development environments, proof of concept labs, installations, account settings, and more are lost.  This will cost us weeks of man hours to repair, and new equipment in the 5K range.  In total we estimate a $15,000 loss.

I know- peanuts to the Hackers and the other big businesses being held ransom, but it is taking down my small business.

Microsoft is not being held accountable by anyone because of all the other issues facing the world today.  They are not a company we should avoid, they are an enemy that should be destroyed.

Update - Right after I posted this I went to feed our Beta Fish - Alex.  He has passed away.  He has been here for 3 years.  I am also holding Microsoft responsible for this.  When you are in league with the devil, your reach is endless.

Windows 10 Review

Pure crap. Released too soon with way too many issues. I completely regret putting it on my bare metal. I only ran Windows 8/8.1 in VMware Fusion on my Mac.

I totally screwed the pooch and installed on my Alienware.

Issues include but are not limited to-

• Cannot recognize my exFat formatted hard drives - which is a Microsoft designed format
• Cannot copy large files - Backing up my Virtuals to external hard drives continuously fails
• Cannot list all the applications i have installed in the start menu- Google "512 apps windows 10 start menu"
• Screen Flickers are going to give me a seizure!!!
• I forgot how much I DID NOT miss the Blue Screen of Death. Luckily now it is sometimes black!!!
• Windows Update is now more of a virus than a tools. You have zero control over it.
• Wi-Fi works when it feels like it. Non-repeatable issues
• All my browsers have issues
• Edge = Turd... Who is the world design that mess??? Fire them... NOW!!! It is not a browser. It is an ADHD nightmare application.

Do yourself a favor and stick with Windows 7. I messed up and went with the every other release from Microsoft is good theory.

Yep, I got it for free. If they want me to install it anywhere else it will cost them $500 per box!!!

DevOps: A Software Architect's Perspective Book Review

This is the first DevOps book that shows a realistic and achievable view of the full implementation of DevOps. Most of the books and other literature I have read on DevOps are all about the culture, the attitudes, how it relates to Agile and Lean practices, and a high level view of microservices. This book includes all that, but they are not its main focus, and it goes several steps further with respect to the architecture and infrastructure needed for the implementation. The book is broken down into 5 parts. I have listed each part below along with the chapters they include. Part One: Background Chapter 1. What Is DevOps? Chapter 2. The Cloud as a Platform Chapter 3. Operations Part Two: The Deployment Pipeline Chapter 4. Overall Architecture Chapter 5. Building and Testing Chapter 6. Deployment Part Three: Crosscutting Concerns Chapter 7. Monitoring Chapter 8. Security and Security Audits Chapter 9. Other Ilities Chapter 10. Business Considerations Part Four: Case Studies Chapter 11. Supporting Multiple Datacenters Chapter 12. Implementing a Continuous Deployment Pipeline for Enterprises Chapter 13. Migrating to Microservices Part Five: Moving Into the Future Chapter 14. Operations as a Process Chapter 15. The Future of DevOps The first chapter introduces DevOps and puts it into context with respect to the rest of the book. The definition of DevOps the authors provide focuses on the goals, rather than the means- DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. They also identify five different categories of DevOps practices that help define their definition of DevOps. I have repeated them below. 1. Treat Ops as first-class citizens from the point of view of requirements. 2. Make Dev more responsible for relevant incident handling. 3. Enforce the deployment process used by all, including Dev and Ops personnel. 4. Use continuous deployment. 5. Develop infrastructure code, such as deployment scripts, with the same set of practices as application code. Chapter 1 also talks about the reduction of coordination and different barriers that can present themselves. The barriers include the culture, type of organization, the goals operations verses development, silo mentality, tool support, and personnel issue such as the difference in salaries between developers and operation staff. Moving operation tasks to a developers plate may not make much sense if the time to do the task is not drastically reduced. Chapter 2 gives a nice introduction to using a cloud environment as a platform. The way in which this book describes the implementation of DevOps, the cloud is a key component. The chapter does a really great job of introducing a ton of material in a very concise way. They start by introducing and discussing the characteristics of the cloud- on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Chapter 2 also covers the 3 types of service - Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The authors go into detail of how the cloud impacts DevOps - the ability to create and switch environments simply, the ability to create VMs easily, and the management of databases. Chapter 3 is a discussion of the core concepts and phases of Information Technology Infrastructure Library (ITIL) and how traditional IT Ops and DevOps interact. Part 2 covers the deployment pipeline. This part is where the microservice architectural style is covered. Deploying, monitoring, debugging, performance management, testing, and team skills are all different than what most development teams are going to be used to. Most teams will not be able to achieve instancing a microservice architecture, for various reasons, but there are some really good practices in this part of the book that teams can achieve. I just got done researching microservices and NServiceBus. I came to the conclusion I would not be able to move in that direction in my current environment. Although team skills where of some concern, the culture is what killed the possibility. It is a command and control environment that is anything but transparent. In order to make such a fundamental shift in the way things are done there would have to be major changes. The environment allows for no agile or lean practices, although it claims to be agile, and is completely closed to change. Certain parts of the book may come across as completely academic and unrealistic, but depending on your environment all best practices and software development principles written by the gurus of our profession may be unrealistic. Do yourself a favor and push through. The case studies do a great job of taking the first three part of the book and showing how organizations are doing their best to move towards a DevOps environment. I thought the case studies were very thorough, maybe even too thorough. Although I think SEI's books contain some of the most important information that has been released in our industry, their books are not always the easiest to read. For as short as this one is, it took me quite a while. A lot of that was my schedule, but not all of it. I can tell you from experience that most of the places I go think the same thing about all of SEI's materials. They mostly view it as purely academic. They are wrong. The places that have allowed me to practice the processes found in Software Product Lines: Practices and Patterns, Software Architecture in Practice, Documenting Software Architectures: Views and Beyond, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, CMMI for Development, and The CERT Guide to Insider Threats, have seen how well their advice works. Places that don't allow me to apply the practices only did themselves a disservice because I did them anyway. It is the only way I know how to successfully build complex software successfully. For those places that micromanaged my activities to make sure I was not wasting time documenting or planning I had to tell - Find someone else to do it. I don't know how to build something wrong, and I have no interest in learning how to. Right now in my current environment they would love me to come in, sit down, shut up, and just go with the flow. The problem with that is the flow is currently taking us down a toilet hole, so I have no choice but to go against the flow! If DevOps can make it across the chasm you will be very happy to have the material found in this book in your arsenal of knowledge.

DevOps: A Software Architect's Perspective (SEI Series in Software Engineering)

DevOps: A Software Architect's Perspective (SEI Series in Software Engineering)

Scaled Agile Framework (SAFe) LiveLessons Video Series Review

This is a review of the Scaled Agile Framework (SAFe) LiveLessons video series. Below are a list of lessons covered.

Lesson 1: Introducing the Scaled Agile Framework
Lesson 2: Thinking Lean and Embracing Agility
Lesson 3: Applying SAFe Principles
Lesson 4: Implementing an Agile Release Train
Lesson 5: Plan a Program Increment
Lesson 6: Execute a Program Increment
Lesson 7: Implementing the Agile Portfolio
Lesson 8: Scaling Leadership—A Learning Journey

The Review
The Agile buzzword has done a lot of damage, but so has SOA, Lean, Scrum, Cloud, as well as one of the latest buzzwords- DevOps. The true processes and architectures that those buzzwords represent, when used in the right context, and the right way, have made the software development world a much better place to be.

I have said it at least a hundred times, so one more time won't hurt- none of these processes and architectures are intended to make building software easier, they are intended to enable you to succeed. The one big requirement for success with these processes and architectures is that teams need to have a lot of experience and skills. One way to learn about the skills needed are through books and training videos like this one.

SAFe was the first enterprise level agile process and it is still the most comprehensive and complete enterprise level agile process. What baffles me is the number of enterprises I have been in that have not come close to implementing 10% of the needed process activities at the different levels of the enterprise, yet they call themselves agile and lean. The one thing this video series brings to light is just how complex and advanced agile processes are. In his book on SAFe, the video presenter says, "it is not easy, it is agile".

I liked this whole video series. There is a ton of great information in it and if you look into the references you will learn a ton. Some of my favorite topics were the SAFe House of Lean, SAFe principles, coverage of the agile manifesto, limiting work in process (WIP), WSJF (Weighted Shortest Job First), Agile Release Trains (ART), budgeting, and scaling leadership.

The SAFe House of Lean coverage is great. The presenter uses a different parts of a house to help visualize Lean. The roof is the goal - Value, the three pillars are - Respect for People, Product Development Flow, Kaizen, and the foundation of the house is Leadership.

Most of the house titles are self explanatory except Kaizen. Kaizen represents driven, relentless reflection and continuous improvement. Organizations make small, steady improvements to effect significant, lasting change over time.

The SAFe Principles are a great compilation of Lean and Agile principles that SAFe is built upon. They are listed below.

Take an economic view
Apply systems thinking
Assume variability, preserve alternatives
Manage risk and efficacy with fast, synchronous learning cycles
Develop systems incrementally, integrate and test frequently
Facilitate flow by reducing batch sizes, managing queue lengths, and limiting WIP (work in process)
Base milestones on objective evaluation of working systems
Synchronize with cross-domain planning and collaboration
Unlock the intrinsic motivation of knowledge workers
Decentralize decision-making

The presenter does a great job of covering the agile manifesto. He points out that they did not say "do not do the things on the right" but rather find the things on the left more important. One of the most damaging thinks the agile manifesto has done is allow teams to interpret it to mean no more documentation and no more architecture is needed.

I do documentation, proof of concepts, and architectural diagrams because it helps me think through the process of how the artifacts will actually be built. The architectural artifacts also provide the Rosetta Stone of the project between the technical and nontechnical team members. Without the exercise of documenting I cannot do due diligence with respect to correctly creating the simplest yet most effective solution. From what I've seen nobody can. That is of course unless they've done the solution many times in the past. I have been fighting for years to get architecture and documentation back into the processes that need it. Thank goodness the agilists are finally speaking out on the topic. Processes like SAFe and DAD (Disciplined Agile Delivery) have grounded the agile world back in reality, and they do not pull punches.

Too much work in process (WIP) is a huge problem, especially in a command and control environment. They have no concept of context switching, or the damage it does, and they think the more they pile on the better they are managing. Most days I see people running around like chickens with their heads cut off, completely ineffective and getting nothing done, except moving onto the next fire. I am actually two or three days ahead, every day I take off, because I'm not there to fight fires and have tasks added to my queue. Every project that is done is done because it finally becomes a fire. Systems that should've been taken off-line years ago are finally being taken off-line because they will no longer run. Most of these issues can be shown to relate back to work in process, and never having the time to actually complete tasks and complete them right.

I really like the way SAFe emphasizes leadership and not management- "SAFe Lean-Agile leaders are life-long learners and teachers who help teams build better systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking, and Agile software development."

I am not a manager, but as an architect I am always managing. If I simply managed, no one would do what I ask. I learned a long time ago I must be willing to jump in and do first what I expect others to also do.  It was the only way I could get my developers to do documentation, learn patterns, and be willing to learn to deal with complexity by working towards simplicity.  I had to do it first.  It was a small part of the mentoring process needed to implement a SDLC on the projects I led.

It seems to me agilists like to assume all employees can be great team members because of their need for cross functional teams filled with people that are generalists. SAFe says agile team members is consisting primarily of developers and testers, but may include other necessary roles as well (e.g., technical lead, system architect, technical writer, etc.), which I agree with. Specialists are needed in agile environments more than they were in traditional SDLCs. A system of any complexity must have the architecture in place to support rapid change, which means you better have an architect that considers modifiability one of the most important quality attributes. Enabling modifiability while not sacrificing performance and simplicity is not easy.

I cannot stand the saying "There is no such thing as a bad employee, just bad managers". That seems to be the theme that all agilists continue to stick with, or they just avoid the topic of management altogether. In my experience a bad manager can shut down good employees, they can be inexperienced enough to hire bad employees, and they can completely destroy an environment, but there are also people (workers) that are, or have become, unteachable.

I won't go into much on the topic, but I do think SAFe should start providing some guidance on it. All I will say is you must accept that everyone will not survive the transition to an agile environment and that is ok. Change is change, and it is the responsibilities of that position that are changing. If the employee filling the position changes, great. If not, you change the employee in that position. There are no other options.

Don't get me wrong, management can do much more damage than bad employees. I have worked with about 5 developers that I could trust to know more than me about structuring code, know the nuances of the languages we were using, and have work done before they are asked to do it. In the environment I was in with the worst managers I have ever experienced, I witnessed one of them simply crushed.

Sometimes it is necessary to break the will of a young talented but stubborn employee, but you should never break their spirit. When you break their spirit you change something so foundational within their core that they end up undependable and dangerous. They become an insider threat that needs to move on so they can reclaim their dignity and passion.

The presenter provides nice coverage of long term planning. Although it is nice to think you do not need to have any long term planning in an agile process, you cannot do without it. Architecture requires long term planning in order to put a framework in place that allows for agility. An architecture that does not support change, shuts you down before you get started.

There are three parts on Agile Release Trains. These are teams of teams created at the program level that are responsible for delivering increments of value in a value stream. The three parts are Implementing an Agile Release Train, Plan a Program Increment, and Execute a Program Increment.

There is a lot on budgeting and it is rather radical compared to how I see budgeting done at most places. I see it fudged, shoved, twisted, and stretched to make it look like it is working, but it is just a hoax. Pay very close attention to the presenter, because odds are your budgeting does't work either, and trying something new cannot really hurt.

WSJF (Weighted Shortest Job First) is a great process for figuring out what you should do next. It is a comprehensive model for prioritizing work based on the economics of product development flow. WSJF is calculated as the Cost of Delay divided by job duration.

Leadership was the topic of the last module. The best leader I ever met was a project manager I worked with years ago, 15 years or so ago. My first project with her was to develop a navigation system for a fairly massive web site that was backed by a custom built administration tool. It housed GE Fanuc Automation Corporation's complete inventory.

My meeting with the company's developers to go over the requirements for the navigation system ended with me telling them it was not possible to build it the way they designed it. They said, figure it out. I said that could take a very long time. Their response was, your contract is 6 months and renewable so who cares. Just make sure you bill the right account. That was the attitude of everyone I had met their up to that point, but I had not worked with her prior to this.

The project manager came back to my desk everyday asking when it would be done, and I said "I do not know", she looked at me weird and walked off. After 2 weeks of that routine I told her not to ask me about work anymore. If she wanted to talk about the weather, or her weekend, fine - but stop asking me when it will be done. She looked at me like she wanted to slap me and then walked off.

She came back a few hours later and asked me why I said that. I told her it was because I told you it was impossible to build the way you want it, and you told me to do it anyway no matter how long it takes. She asked me to explain. Apparently the internal development team had not told her what I had told them.

She asked me how it should be done. I drew a few diagrams, and explained why it could not be done the way they wanted, but showed her how it could be done, and still meet all the customer's demands. She asked how long that would take and I said 3 weeks. She said do it, and I did. It was fully tested and ready for production promotion in 3 weeks.

That set in motion a new way of doing things at that company. The business had been telling her she needed to have it done in 2 weeks from the beginning of this ordeal. The dates came and went until I told her 3 weeks. She told them 3 weeks, they said no 2, she said sorry 3, and we delivered in 3 weeks. The next thing they said they wanted in 1 month. She asked me how long and I said 2 months. She told them 2 months. They were not at all used to this behavior, but after we delivered several projects in the time we promised, the business started trusting our team.

That sounds like a ho-hum story, but what followed was the development of a cross functional team that was completely transparent with the business, allowing the business to be completely transparent with the client. Over the next year and a half we developed iteratively, creating use cases, doing proof of concepts, requirement specifications, architectural diagrams, and had a blast. We did code reviews by having the whole team try to find issues with the code, if they found a certain amount of issues, the team member being reviewed had to buy the team ice cream.

We made deliveries every few weeks, which was fast enough to keep new requirements in the next release and had refactored the code so that it was very malleable and could be easily changed and tested. We achieved the state of agility. Keep in mind that agile is a state of being, not a process, not a set of development practices, not a way of budgeting, and not an architecture. All those things must be done in a certain way in order to achieve an agile state on a project.

Where did we learn how to do all that? Our team used 4 primary books to guide us - Managing Software Requirements: A Unified Approach, Software Architecture in Practice, Design Patterns: Elements of Reusable Object-Oriented Software, and Applying UML and Patterns. Two of them are now available in their third edition. Software Architecture in Practice - Applying UML and Patterns, and Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.

In case you don't know- Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise is all about SAFe.

The video covers three leadership styles - Leader as Expert, Leader as Conductor, and Leader as Developer. The presenter goes over the characteristics of each type, and the challenges each type has. He covers a ton of other valuable information as well.

I liked keeping the SAFe web site up while going through the videos. Following the topics on the site helped me get familiar with the current release of SAFe. I read the book a few years ago and still keep it handy, but the team developing SAFe has been hard at work adding new material. When I read the book, this site was just the process picture and some release dates, now it is a huge repository of valuable information.

The videos cover a bunch of valuable templates. Following along on the site allowed me to grab them as they were being covered.

I also recommend doing the exercises as the presenter asks you too. It really helps to do them because it makes you think the way the presenter wants you to think. Just watching him do them is good, but doing them yourself helps you absorb the topic more.

Do not make the mistake of thinking that you can take SAFe as is and implement the process in your enterprise. What you find here is the first thing needed for software process engineering, a repository of assets, principles, practices, activities, and patterns you can use to instance a process. The second half is instancing the process in your environment. Think of it like a module of classes, some of them he would override, some of them you would use as is, some of them you would not need to use, and you would add your own functionality.

The Scaled Agile site provides Enterprise SAFe which allows organization to customize SAFe. I used EPF (Eclipse Process Framework) to build a process for the State of Pennsylvania using material from Scott Ambler, SEI, Sparx, Microsoft Pattern and Practices group, and baseline processes like OpenUP and Scrum so I know what it should do, but have not had the opportunity to use or see it in action yet. I just wanted to point it out.

Over all I don't think you can afford not to watch this video series if you are planning on introducing agile processes at an enterprise level. Even if you aren't, watching the series will provide you with a tons of tools on teamwork and leadership. I have watched several parts of it several times. Get more information about the videos here.

Bulletproof Android: Practical Advice for Building Secure Apps Book Review

Sometimes I really annoy myself. When I received this book I was already reading Android Hacker's Handbook. When I saw the size of it, I put it on the bottom of the pile of books in my reading queue. I then got Android Security Internals and that was not a quick read. I am glad I finally picked this one up off the pile. For a small book, it contains a ton of great information. In the first chapter they introduce several security guidelines including PCI Mobile Payment Acceptance Security Guidelines, Google Security, HIPAA Secure, OWASP Top 10 Mobile Risks (2014), and Forrester Research’s Top 10 Nontechnical Security Issues in Mobile App Development. I have listed the chapters below. 1. Android Security Issues 2. Protecting Your Code 3. Authentication 4. Network Communication 5. Android Databases 6. Web Server Attacks 7. Third-Party Library Integration 8. Device Security 9. The Future The book is very concise, but the author targets topics that can be taught in short to the point chapters. For example, Chapter 2 does an awesome job of introducing obfuscation, covering the different types, and then showing us how to use ProGuard and DexGuard. The chapter concludes by showing the differences of what you can accomplish with decompiling and disassembling. This book is different from the other Android security books I have read because it is not a book for the hacker, it is more of a book for the architect and developer. It is a book about the tools available to protect your application, not break your application. It is also about the best practices that are available for us to follow in order to achieve a stable and secure application. Although the other books I have read were fun, this one applied more to what I need to know to do my daily job. I don't go to work to hack applications, I go there to build safe and secure ones. The code that comes with the book is great. Best of all, it just opens, builds, and runs in Android Studio. I have been using ADT, but just recently made the switch to Android Studio. This is the first Android book that has come with code that just ran for me, and was also actually worth running and digging into. The author's writing style makes the book an easy cover to cover read. It was also nice to have a small book to carry around for once. I highly recommend this book to any architect or developer that is interested in learning more about Android security topics for the architect and developer.

Bulletproof Android: Practical Advice for Building Secure Apps (Developer's Library)

Bulletproof Android: Practical Advice for Building Secure Apps (Developer's Library)

Swift for Programmers Book Review

This is one of the best laid out programming books I have read in a while. The way it starts out providing summaries of Swift features found in other programming languages, Swift features that eliminate common programming errors, the list of Cocoa and Cocoa Touch frameworks, new key features in Xcode 6, special characters, numeric and boolean types, operators, conditional and loop statements, compound assignment operators, Classes, access modifiers, properties, initializers, methods, value and reference types, and making use of built in frameworks is perfect for developers from any other language. By the time you are done the first few chapters you have gained a great deal of knowledge about Swift that is familiar from your experience with other languages. Below is a list of all the chapters included in the book. 1. Introduction to Swift and Xcode 6 2. Introduction to Swift Programming 3. Introduction to Classes, Objects, Methods and Functions 4. Control Statements; Assignment, Increment and Logical Operators 5. Functions and Methods: A Deeper Look; enums and Tuples 6. Arrays and an Introduction to Closures 7. Dictionary 8. Classes: A Deeper Look and Extensions 9. Structures, Enumerations and Nested Types 10. Inheritance, Polymorphism and Protocols 11. Generics 12. Operator Overloading and Subscripts 13. iOS 8 App Development: Welcome App 14. iOS 8 App Development: Tip Calculator App A. Keywords B. Operator Precedence Chart C. Labeled break and continue Statements After the initial introductory chapters the book digs deep into different topics by giving each major language feature a chapter of its own. The chapter names are reflective of the topics covered. Object-oriented programming topics are covered throughout the book when topics being covered create the right context to cover them. However, chapter 10 is dedicated to covering Inheritance, Polymorphism and Protocols. This chapter does a good job of explaining how Swift is different than most object-oriented languages because it does not have a common superclass from which all other classes inherit basic capabilities. The last two chapters of the book give us a glimpse into developing iOS 8 applications. Each chapter builds a small application and covers a bunch of topics at a high level. They also introduce storyboards and the Xcode interface. These two chapters are from the book iOS 8 for Programmers: An App-Driven Approach with Swift, which gives you an idea of whether or not you would like to read a book which takes you through building a bunch of small applications to introduce you to iOS 8 development. The book includes code samples you can download, but one of the things I liked best about the book is the amount of code found in the book and the format in which they were presented. I could carry the book around and read it without feeling like I had to run the code samples on my Mac. The samples include the results of running the code in the book. I know a lot of books do the opposite, making you type everything in, which is effective for the beginner, but this format is much more appealing to me. The downloadable samples are very well organized by chapter and then labeled with the same figure name used in the book, making finding the really easy. I upgraded to iOS 8.3 and Xcode 6.3 and all the samples easily upgraded. I didn't have any problems with any of the examples before or after the upgrade. Another thing I like about the book is the sidebars throughout the book. They have 5 different types of them including Good Programming Practices, Common Programming Errors, Error-Prevention Tips, Performance Tips, and Software Engineering Observations. They are usually 1 to 4 sentences, and are related to the material being covered in the section they are placed. I saw that there is now a Swift Fundamentals LiveLessons available by the author. I have not seen this course, but have seen other LiveLessons, and they are usually pretty good. There are a few sample videos available on the publisher's web site. The author's writing style and the layout of the book makes this an easy cover to cover read. The way the topics are covered also makes the book a good reference. There is no fluffy filler. The authors get right to the point of a topic and stick to it until it is thoroughly covered. All in all I think this book is the perfect place for the experienced programmer of C#, Java, Objective-C, or C++ to get started with Swift.

Swift for Programmers (Deitel Developer Series)

Swift for Programmers (Deitel Developer Series)

Security in Computing (5th Edition) Book Review

This book is a beast!!! It is 100 % textbook, with a lot of exercises at the end of the chapters. If your class uses this book, get ready for a fire hose of information. It covers a ton of topics and covers them in depth. Although it is a text book the authors do there best to keep it interesting. I really enjoyed the sidebars that include true stories of security breaches. I really like the ones that find out what the criminal was thinking. Some of the reasons for doing what they do are nuts. One of the biggest problems with security I see today is the security teams oftentimes don't know what to secure, or how to secure stuff when they do. This book starts out with a really nice introduction to what computer security is. The author discusses Values of Assets, the Vulnerability–Threat–Control Paradigm, Confidentiality, Integrity, Availability, Types of Threats, Types of Attackers, Risk and Common Sense, Method–Opportunity–Motive, Vulnerabilities, and Controls. By the time you are done this chapter you have a high level few of today's security issues. 1. Introduction 2. Toolbox: Authentication, Access Control, and Cryptography 3. Programs and Programming 4. The Web—User Side 5. Operating Systems 6. Networks 7. Databases 8. Cloud Computing 9. Privacy 10. Management and Incidents 11. Legal Issues and Ethics 12. Details of Cryptography 13. Emerging Topics I was glad to see information on regulations, compliance, and laws. They can wreak havoc on an organization's productivity when left to an unqualified security team. I usually find that IT organizations that have locked down everything from the Internet to your USBs, have no concept of how to implement security in a managed and efficient way. Years ago I was the lead research and development on a contract with the state. They allowed no internet except for 2 PCs that all 250 people on the project had to use. 90% of the time they were tied up with people checking their personal email. That was the days before smart phones. I would have to go home, research stuff, download it and burn it to CD, and take it in to work. I understand the thoughts behind natural immunity, but separating yourself from the world you are trying to successfully build software for, leads to software that doesn't meet the needs of that world. More recently I was tasked with building a mobile application. The company had a guest wireless connection in place, but it was so locked down we couldn't use it. We needed to get data plans for the phones to test the applications. They also had emails with attachments reviewed by help desk personnel that would then release them. They basically are operating like the state project I mentioned above. Yet every security audit is failed. This book does a great job of covering all the security topics you need to know about to work successfully in a decent size enterprise. The detail and depth of each topic amazed me. A highlight of this book is that after the detailed introduction at the beginning of the book, each chapter contains topics you can read in isolation, while at the same time they are logically tied together. Another highlight is that the book contains both timeless information and current information doing a really good job of tying the history of a topic to the current state of a topic. For example, the chapter on Cloud computing contains basic information on SaaS, PaaS, and IaaS, as well as sidebars on current research happening today that isn't quite ready for release to the world. Over all I highly recommend this book not only students that need it for a course, but to everyone that has any interest in learning more about the world of security. For the amount of information and the clarity of its delivery, this book is absolutely worth the price.

Security in Computing (5th Edition)

Security in Computing (5th Edition)

Swift in 24 Hours, Sams Teach Yourself Book Review

This book has Beginning to Intermediate on the back cover. I would recommend you put that into the context of learning Swift, not learning Object-Oriented Programming. The book does an excellent job of covering the Swift language in detail and it jumps right in after a short introduction to the available development environments - Xcode, playgrounds, and REPL (Read-Eval-Print-Loop). REPL is kind of a command line version of playgrounds running in terminal. The introduction is hour 1. There are 24 hour long lessons. I have listed the lessons below to show you what is covered. Hour 1. Introducing the Swift Development Environment Hour 2. Learning Swift’s Fundamental Data Types Hour 3. Using Operators in Swift Hour 4. Working with Collection Types Hour 5. Understanding Optional Values Hour 6. Controlling Program Flow with Conditionals Hour 7. Iterating Code with Loops Hour 8. Using Functions to Perform Actions Hour 9. Understanding Higher Order Functions and Closures Hour 10. Learning About Structs and Classes Hour 11. Implementing Class Inheritance Hour 12. Harnessing the Power of Enums Hour 13. Customizing Initializers of Classes, Structs, and Enums Hour 14. Digging Deeper with Properties Hour 15. Adding Advanced Type Functionality Hour 16. Understanding Memory Allocation and References Hour 17. Using Protocols to Define Behavior Hour 18. Using Extensions to Add Type Functionality Hour 19. Working with Optional Chaining Hour 20. Introducing Generics Hour 21. Adding Interoperability with Objective-C Hour 22. Interacting with User Interfaces Hour 23. Asynchronous Programming in Swift Hour 24. Learning Swift’s Standard Library Functions The hour's titles do a great job of describing exactly what is covered. Sometimes authors like to use goofy chapter titles that need interpreted, but not in this book. Having the topics broken down into individual chapters makes this book a good reference. Although you can jump into any topic, the book's chapters do build on each other. If you can, I would recommend reading the book cover to cover and then keep it around as a reference. Each topic is thoroughly explained but the author did a really great job of keeping the chapters short enough that they can be read in an hour. I have had many "in 24 Hours" books and many of them had 2 hour chapters. This book is definitely the lunch break book. I am reading four books on Swift before moving on to iOS 8. This might seem like over kill since I have spent a lot of time in Objective-C, but this is what I do to learn when I am trying to learn something I am not using at work. I am not that quick or smart, so I need to repeatedly pound stuff into my head for it to stick. Although I started all four books at the same time this is the second one that I started running away with and finished. The reason for that is this one is in the middle of them as far as being robust goes, but it still contains straight to the point content. No filler at all. What made this one a little more robust than the first one I read was each chapter end with a Q&A section, a Workshop- Quiz with answers, and an Exercise. These really help to drive home the topics covered in the chapter. The book comes with all the examples available for download. They are all in playgrounds, except the last 3 chapters, which are in projects. The examples organized by chapter. This is not an iOS 8 book, it is a Swift language book, so don't expect to be building apps at the end of the book. Although, you can expect to get started with iOS 8 when you are done this book. As I mentioned above the author says you do not need prior programming experience to get through the examples in the book. He is probably right because he does a really good job of walking the reader through them. However, if you have no prior programming experience, you are going to have to pick up some books on Object-Oriented Programming before moving on to iOS 8. All in all, I found the book a pleasure to read. The author's writing style is great, and the chapters were the perfect size to read over lunch. I recommend having your Mac with you when you are reading it. A few times I used an online swift compiler to run through some of the examples. I only had my iPad with me. If you are interested in learning Swift, this is a great place to start!!

Swift in 24 Hours, Sams Teach Yourself

Swift in 24 Hours, Sams Teach Yourself

Sparx Systems Releases Enterprise Architect 12

There is only one tool I have open more than Xcode, Visual Studio, Eclipse, and Android Studio, that tool is Sparx Enterprise Architect. Below is their recent announcement of Enterprise Architect 12. There is no tool on the market that compares to Sparx Enterprise Architect at such a great price. If you have never checked it out, do yourself a favor and check it out now!!

Continuing a long term commitment to the development, extension and refinement of its flagship UML based modeling tool, Enterprise Architect, Sparx Systems is proud to announce the official release of Enterprise Architect 12.

As one of the most feature rich and exciting product releases to date, Enterprise Architect 12 is the result of extensive community consultation, in house innovation and overall optimization. It includes new and unique tools that tightly integrate data models, wire-frames, information meta-models, XSD, XML, documents and code in a robust and collaborative environment. Revitalized user interface themes provide a compelling and sleek UI that is both engaging and stimulating.

Registered users can download Enterprise Architect 12 from the registered users download page.

Take a look at some of the major new features in Enterprise Architect 12 at: www.sparxsystems.com/ea12
Read through the full list of changes in the: release notes

Some release highlights:
( Use the jump list below to go directly to your area of interest )

User Interface Theming: Significant enhancements to the look and feel of Enterprise Architect

Click here for larger image 

Portals Window: An all new tool to provide rapid access to common commands, searches, recent documents, user interface theming, workspace layouts and more

Navigator Bar: An all new toolbar designed to provide better control and management of your current context within the model

Database Engineering Toolset: Database Builder view added to provide a database centric view of your Data Model

Click here for larger image

GUI Wireframing: All new fully featured and comprehensive Wireframing library for modeling common devices and user interfaces

Click here for larger image

Schema Composer: A new powerful toolset to rapidly design and build XSD and similar data definitions from a model subset

Diagramming: Many improvements to the behavior, drawing and navigation of diagrams have been added. Improvements include: New Drawing Styles, Diagram Quick Keys, Shape Script enhancements and more

Redesigned Property Dialogs: The Object Properties dialog has been updated to bring the focus to the name and notes of any element

Start Page Updated: A clearer and simpler jumping off point for models and portals

Main Menu: Changes to simplify and focus access to tools

XSLT Debugging: Build, debug and execute XSL Transforms

Click here for larger image

XML Editing and Validation: Improved XML/XSD editing, navigation and validation

Document Handling: (Enterprise Architect as 'Default Program') Load supported file types by default into Enterprise Architect to provide a better editing and viewing experience

XMI Merge: Added support for merging multiple XMI 1.1 files originating from the same baseline into a model

MDG Link for Eclipse and MDG Link for Microsoft Visual Studio: Now included with Enterprise Architect Professional and above

Click here for larger image

Project Management Profile: and new Risk Taxonomy Profile

Reporting & Document Generation: New tweaks and refinements help you build the best reports yet

BPMN: Many updates, conformance improvements and diagramming improvements

Plus added support for multiple information meta-models such as:

• UN/CEFACT
• UBL
• CIM
• NIEM

Further changes include Code Engineering, Execution Analysis, ArcGIS, ArchiMate, GML, Specification Manager, XMI, Version Control, Locking and more.