Podcast appearances and mentions of jonathan sol

Tracklist: 1. Thomas Nikki & Jonathan Solís - Canopus (Extended Mix) [Digital Society Recordings] 2. Simon Patterson feat. Falling Off Maps - The Neon Cross (Extended Mix) [Armind] 3. CRITICAL TRACK: Ana Criado & Raz Nitzan - Meet Again (Ferry Tayle Remix) [Amsterdam Trance Records] 4. Kaimo K & Hanna Finsen - My Silver Lining (Original Mix) [Amsterdam Trance Records] 5. John O'Callaghan, Paul Skelton & Sue McLaren - Power of Now (Extended Mix) [Subculture] 6. Driftmoon - Ballet Dancer (Extended Mix) [Subculture] 7. James Dymond - Layan Bay (Extended Mix) [FSOE] 8. system ck - Reminiscence (Original Mix) [Molekular Sounds] 9. Vikram Prabhu - Forbidden Knowledge (Extended Mix) [Ablazing] 10. Driftmoon - Feel The Waves (Original Mix) [A State Of Trance] 11. Luke van Ness - Blue Destiny (Extended Mix) [Extrema] 12. CRITICAL CLASSIC: Lange vs Gareth Emery Another You Another Me (Original Mix) [Lange Recordings]

Download my official Android App: djphalanx.com/getitongoogleplay Official Uplifting Trance Sessions Spotify Playlist: spoti.fi/3jyMmX0

Enjoy fresh new music produced by PRAANA & Julia Church, Super8 & Tab, Ashley Wallbridge, Thomas Nikki & Jonathan Solís and more.

¿Cómo funcionan los anuncios personalizados? ¿Es posible saber de antemano cuáles van a ser las zonas más concurridas de un centro comercial? Nos lo cuenta Jonathan Solís, CEO de Flame Analytics, con quien hablamos sobre las aplicaciones de la analítica de datos en sectores como el retail o el transporte urbano, sobre el marketing de proximidad y la importancia del Cloud para almacenar y disponibilizar toda esta información. ¿Existe el panettone con beacon?

The 10x Coder is often positioned as a mythical developer who can always save the day. Saron and Clive investigate how much of that myth is grounded in truth.  Greg Sadetsky argues that coding is much like professional sports—some athletes are bound to be much better than those starting out. Brianna Wu and Bonnie Eisenman pick apart the myth by sharing how much they have had to clean up after supposed 10x Coders. Jonathan Solórzano-Hamilton recounts the story of "Rick," a self-proclaimed rockstar developer who assumed too much. And everyone considers the benefits of the 1x Coders—because what use is code without ideas and experiences to guide development? If you want to read up on some of our research on 10x coders, you can check out all our bonus material over at redhat.com/commandlineheroes. Follow along with the episode transcript.

Entrevistamos a Jonathan Solis, CEO y fundador de Flame Analytics, una plataforma de analítica de comportamiento en tienda física y marketing geolocalizado.La OmniCanalidad sigue siendo el Santo Grial del Comercio, un objetivo claro al que hay que llegar, pero que tiene tantos matices y resquicios, que se plantea como un camino casi sin final.Muchas veces el comportamiento de los consumidores puede resultarnos contraintuititvo. Por ejemplo, ¿dónde se realizan la mayoría de las compras después de una búsqueda desde un dispositivo móvil? Uno entendería que online, pero resulta que en el 73% de los casos se realizan en tienda física. Esto se explica más claramente cuando entendemos que el 82% de los compradores utilizan el móvil desde tiendas físicas para consultar acerca de productos que están a punto de comprar.Como consumidores ya somos OmniCanales, de hecho, un estudio de Google nos apunta a que ya el 90% de los compradores online aseguran estar utilizando distintos dispositivos para realizar una única compra. Y esto pasa porque no pensamos en qué canales vamos a comprar las cosas, si no que tenemos necesidades que queremos cubrir y compramos online o en tiendas en función de nuestra conveniencia y nuestro contexto.Yo mismo lo hago a menudo, utilizo mi teléfono para cotillear, a veces paso por tiendas para inspirarme y sigo cotilleando algo más online, y en función del tipo de compra, acabo comprando en una tienda física o me voy a

Entrevistamos a Jonathan Solis, CEO y fundador de Flame Analytics, una plataforma de analítica de comportamiento en tienda física y marketing geolocalizado. La OmniCanalidad sigue siendo el Santo Grial del Comercio, un objetivo claro al que hay que llegar, pero que tiene tantos matices y resquicios, que se plantea como un camino casi sin final. […]

This episode is for anyone who wants to effectively orchestrate a development process without becoming the butt of their team’s water-cooler jokes. It's more attainable than you think, because it's all about process. Don't be a Bill Lumbergh - be awesome. Written and read by Jonathan Solórzano-Hamilton: https://twitter.com/jhsolor Original article: https://fcc.im/2GW6xFX Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: Laurence Peter formulated the principle that “managers rise to the level of their incompetence” in 1969. In particular, non-technical leaders have earned a poor reputation with software developers. Office Space depicts the non-technical manager in Bill Lumbergh, pictured above. Dilbert provides the classic “Pointy-Haired Boss.” This article is for anyone who wants to effectively orchestrate a development process without becoming the butt of your team’s water-cooler jokes. I’ll share what I’ve learned over the years managing development and release processes as a manager and software architect at UCLA and Stanford University. The biggest lesson I’ve learned is that the key to sustaining successful software releases is completely non-technical. It’s about process. Some aspects of a development process benefit from technical know-how, but it’s not required. Successfully releasing software into production is much more a question of robust process architecture than design or code alone. For the purpose of this article, we’ll assume you’ve already agreed to start building something. The product approval pipeline is a different process. Today we’re focusing on getting the agreed-upon product from concept to production. What to build Your team needs to assemble a clear roadmap for their code. Architects and manufacturers use blueprints. You should too. Your roadmap should include a set of schematics which each fulfill a different purpose. These schematics differ for individual applications. A user-interface mock-up, application architecture diagram, and business process model are common. More detailed component diagrams such as Unified Modeling Language (UML) diagrams and flow models are often useful as well. Technical expertise lets you use these schematics to critique your team’s architecture and ensure they’re on the right track. Even without technical skill, these schematics will be critical. You can use them to drive productive conversations about product completion. No more will you have to draw a “% complete” out of thin air or best-guess from the development team. You can track the status of each item on the diagram to determine how close the app is to completion. You can also project future velocity based on how quickly the team completed prior components. There is no “right” amount of pre-development documentation, but there is one wrong amount: none. Work out with your team what constitutes an acceptable roadmap before they start coding. The first checkpoint in your development process will be to review this documentation and ensure they’ve met this agreement. What not to build Your team can’t build everything. Nor should they. You need to ensure that your developers have a laser focus on what they actually need to build. Why are you building this app in the first place? Define the key differentiation from existing products. 80% of your team’s time should go toward supporting that differentiation. The schematics you should now have will be helpful here. Does your application include a logging component? A sign-up and login process? There are already excellent free, open-source software (FOSS) frameworks in most languages for these components. Some are available under extremely permissive licenses. Tesla provides a great illustration of this concept. Their first key differentiator was to use a lithium-ion battery to make electric cars competitive with gas. Lithium-ion achieved this by reducing battery weight and increasing range. The first Tesla prototype simply converted a pre-existing electric sports car from lead-acid to lithium batteries. Their first production run was mostly a Lotus Elise roadster (a pre-existing sports car) that had a Tesla battery and motor. The lesson for your team is to use what already exists wherever possible. If you can use or adapt a FOSS package, do it. Even if you need to license for-pay code from somewhere else, it’s almost always worth it. Get all the scaffolding in place quickly so you can test your “lithium-ion battery.” Then you can iterate through and replace whatever will help further differentiate your product without stressing about delaying production-readiness. The second checkpoint of your development process is to review the planned architecture with your team and identify what very limited part they intend to build from scratch. If it sounds like something that already exists, and it’s not the core focus of your product, challenge your team to see why they believe they need to re-do it. Don’t just throw it over the wall Once you have identified what pre-built technologies you’ll use, make sure to review these with your production support group. Database and server administrators will need to plan for installing and supporting any new technologies. This is the third checkpoint in your development process: operations readiness. Keeping the production support team in the loop early is 90% of the secret sauce known as “DevOps.” If you haven’t heard of this, DevOps is the idea that software development and production operations teams should unify under common goals. The proposed benefits include much quicker releases, more reliable code, and more time spent developing due to automation. These are all great boons, but they follow from a strong communication process. Automation follows, not replaces, collaboration. Implementation and Testing Now your team writes the code. Collaborate with your implementation team to devise a process for dividing the work among themselves. There’s no one-size-fits-all approach, and this is where the “soft skills” of leadership dramatically outweigh any technical skill. Some developers will want to hog all the “interesting” work and ignore any drudge work. They may believe that they’re the smartest person in the room and should get their pick of assignments. Others may resist change and only want to do the same kind of work they’ve done before. Lead your team into an equitable distribution of work. Challenge everyone to grow appropriately and to share and collaborate. One more technical aspect of the implementation is that the code must include sufficient automated tests. These are code-defined tests that a test system can execute. If the code’s going to crash, don’t you want these guys’ resumes to be on the line instead of your own? (public domain: US Government photo) Manual “test scripts” where a human interacts with the code to see if it works are insufficient and reflect technical debt. Your technical team should at least include unit tests. Test-driven development is a popular approach for ensuring that critical code is always tested. You can drive a non-technical conversation with your team about their “test coverage” (the portion of the code that is tested). It’s pretty simple: ask them to list their assumptions. Then ask where and how they test these assumptions. The checkpoint at which the code is believed complete by the developers is referred to in my shop as dev-complete. It means the primary development (dev) process is over, but additional code may be written to address issues that come up in the review process. In an agile development process, you will typically divide the implementation process into multiple checkpoints instead of one all-or-nothing deadline. These are typically called iterations. Refer to the roadmap you defined in the first step. Before starting new component(s), ensure that what you’ve already started is at least dev-complete. This provides you with an accurate view of the speed of development and reduces risk. As you complete the iterations, you can push the code to an environment for “acceptance testing.” This involves pilot or test users (or an internal team playing that role) who interact with the partial product. They test to ensure it meets the design expectations and provide feedback on how it could be better. Acceptance testing is not a substitute for the unit testing mentioned earlier. It serves a different purpose. Letting your development team lean on acceptance testing to catch basic functional bugs is a recipe for disaster. Feedback from the acceptance testers can be incorporated into the next iteration. This is another good reason not to bite off a big chunk of the product all at once. You want to leave room to change course once people start playing with the product. Once you’ve accumulated enough tested code to constitute a sufficient product release, you’re ready to begin the release management process. Looking for bugs in all the right places Your developer or team has reached a point where they believe the code is done. Acceptance testers are satisfied with the way the product is working. The next checkpoint in the process is to validate the belief that you have code ready to become a product. Let’s start reviewing the code! You may not be comfortable or have sufficient technical know-how to review the team’s code yourself. That’s ok! You don’t have to. Your process has to. Work with your team to identify a process for code review that works for them. If you have more than one developer, peer code review works great. If you don’t, are there other developers in your organization outside of your team? Work across team boundaries to establish a peer code review program. If there really is only one developer, then sit down with them and have them walk you through the code. Use your schematics as a reference point, and ask them to tell you how the code accomplishes the schematic’s goals. At the conclusion of the code review process, the developer and reviewer(s) should feel comfortable with being held accountable for the code. The code review is also a good time for reviewing two other critical points: documentation and security. I’ve already written about a sustainable documentation architecture — check it out if you’re interested! Security review should be a part of any code review. In general, this involves taking a second look at the code to spot weaknesses where an attacker could exploit it to reveal private data or gain control of the server. It must be done by a technical person. The Open Web Application Security Project (OWASP) publishes a free comprehensive guide to security review. Your developer can do this if they’re the only one on the team, even if they just run an automated security code analysis tool. There are free tools for helping with this process which are linked through the OWASP wiki. Eject, eject, eject! The code has passed the review process. It’s ready to become a product. But that doesn’t mean it’s ready for production. The last checkpoint to clear is deployment readiness. Is your code in a state where it’s easy to deploy to production? This should involve as few manual steps as possible. It also means you need to have a plan for reverting the change in case the code doesn’t work as planned. This is called a “rollback plan.” If you have a separate software operations team, this is where they come back into the picture. They should review the deployment and rollback documentation and let you know if it’s sufficient. If you don’t have these personnel you can perform this step yourself. Make sure that there are clear, simple instructions for deploying the product. There should be very few manual steps, as each manual step introduces a chance for human error. There should be a clear, sufficient plan for returning to the prior state of affairs if the deployment doesn’t succeed. This may be as simple as restoring a backup, or it may involve customer communication or data conversion. Whether the plan is sufficient depends on how thoroughly your team tested the code, and how widely the product is being released. Consider also any risks associated with the product or with this particular release. Once you’ve passed this checkpoint, push that code into production! Post-release Succeed or fail, it’s important to circle back and review how the process went. Did your team accurately estimate the effort required to release a product? Did the testing adequately model the production scenario? Revisit the implementation and testing checkpoints, and review how well the team performed. How is the product running in production? It’s a good idea to visit the operations staff and obtain their feedback. This further creates trust between the development and operations teams, and will lead to more DevOps benefits down the road. Where are the remaining gaps in your product? If they’re in third-party code, now’s the time to consider whether to customize your packages or re-implement from scratch. Otherwise, you now have input on what to build for the next release. Above all, hold yourself and your team accountable for the results of your effort. Accountability facilitates independence and promotes individual growth. As your team grows accustomed to being held accountable for each step in this process, they’ll adjust their performance accordingly. Conclusion You don’t have to be the least bit technical to run a successful software release process. Technical skill can help, but it can also become a crutch. The key to successful software release is a well-documented, well-understood process for moving software through the pipeline from idea to product. You now have a starting point for drafting your own software release process. What’s most important is that you participate with your team in filling in the blanks and creating a repeatable process that works for all of you. It doesn’t have to be perfect for anyone, but it does have to be understood by everyone. You also need to ensure that the velocity of your product through these checkpoints matches the demand for the product. None of these items need to be multi-day show-stoppers. It could be a simple one-page checklist. You need to define a process that fits your environment. As with any process, you should also iterate. Just like with the code, your first, untested draft isn’t likely to be perfect. Tune the process on each run-through and you’ll end up with a smooth, predictable software release path. And remember to brush your hair. You don’t want it looking…pointy.

The concept of a legacy usually conveys permanence, value, and greatness. But what about in relation to your code? In this article, Jonathan explains how his team broke up with their legacy codebase, why it was necessary, and how your team can do the same. Written and read by Jonathan Solózano-Hamilton: https://twitter.com/jhsolor Original article: https://fcc.im/2FEuAcR Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:    The concept of legacy conveys permanence, value, and the greatness we bequeath to our children and our successors in the community. People make ludicrously generous donations to charitable causes to establish their legacy. They create eponymous endowments or buildings and strive to protect the name their children will inherit. It’s therefore striking that software developers have gotten their “legacy” so catastrophically wrong. Google “legacy,” and you’ll see the first definition matches what I’ve laid out for you here. It’s a definition that’s persisted since the 14th or 15th century. The second definition provides a shocking contrast: legacy. adjective (computing) “denoting software or hardware that has been superseded but is difficult to replace because of its wide use. Dictionaries around the internet agree with this definition. It applies only to the field of computing. We developers have managed to invert the definition of our own legacy in the historical eye-blink that is computer science. That’s almost impressive! If you’re an experienced developer, you’ve certainly been tasked with supporting at least one legacy system in your career. For the uninitiated, well — buy a lot of caffeinated beverages. I’m about to relate to you the brief story of our toxic relationship with our legacy codebase. I’ll then describe how we broke up with it, and what we’ve changed to avoid falling back into bad relationships with high-maintenance code. The Breakup It took eight months of seven-day weeks and twelve-hour days to complete our last legacy system overhaul. Our predecessors had pushed code into production for years without writing a single line of documentation. In fact, some of it wasn’t even in source control, as we later learned. But that’s another story. I’m sure you’ve seen gems like this before: ... hundreds of line of incomprehensible code // TODO: Fix this bug!!! ... hundreds more lines in the same method, no idea where or what the bug is That is the approximate ratio and quality of the only documentation we had on the project. I wasn’t exposed to direct sunlight again until April, and I’d had enough. It was time for a break-up. The importance of documentation In his book “The Art of Unit Testing,” Roy Osherove defines legacy code as any code that doesn’t have tests. He was an optimist. I more loosely regard as legacy any code which contains more technical debt than the time it took to write. As our organization had, many development teams fall into the trap of instant-legacy code: code that already fits the “legacy code” label at the time of release. In my experience, documentation is the most important aspect of avoiding such legacy code. I have yet to meet a developer who loves the idea of documentation. On the other hand, I also have never met a developer who loves crawling inside the skull of a stranger to reverse-engineer a legacy implementation without any documentation. As they say, breaking up is hard to do. But in this case, I promise it will be worth it. So let’s get started on converting your legacy into something you’ll be proud to bequeath to your successors. Let’s get documenting! Our approach: four layers of documentation We created, and began rigorously following, a four-layer architecture for documentation. We maintain three layers of persistent documentation for the project through its life-cycle. We also communicate through one layer of ephemeral documentation during our release management process. The three persistent layers of documentation correlate to three different velocities in our development process. We include documentation review as part of code review to avoid falling back into bad habits. // The front lines: in-line comments keep maintainers sane The most granular tier of explicit documentation is in the code. We perform complete documentation of all classes and methods, their inputs, expected outputs, and exception pathways. We also document “unusual” code in-line. As a predominantly C# shop we use /// documentation ubiquitously. This decorates class, interface, and method declarations. The /// helper auto-generates XML stubs to document the nuts and bolts of the API. These pop up when your code is being referenced by an external project or DLL (dynamic-link library), provided that you’ve distributed the debugging files. Our IDE (integrated development environment) renders this as tool-tip help wherever a reference appears. This greatly aids developers, who are diving into our code for the first time, when trying to fix a bug or extend it for a new use case. It’s worth researching your language and IDE of choice to learn how to extend it with contextual help for your libraries. If you’re not used to documenting your APIs, I suggest reading these articles to get started. We also include regular // comments beyond API documentation. We add these wherever the code is counter-intuitive, or if we’ve found a particularly elegant solution to a problem. We also use these to create “to-do’s” for later refactor when putting in a quick-and-dirty fix. These are invaluable to whoever has to come along and revert the change or fix the code. Because it’s in-line with the source code, this documentation changes at the highest velocity — right along with the code it supports. README: making implementation a breeze We use README files as an implementer’s guide. This documentation is for whoever will be consuming our libraries. It serves a secondary purpose as tactical-level documentation of the particulars of the implementation. We use GitHub for source control, so we place readme.md (Markdown) files in each folder in our GitHub repository. GitHub very nicely renders Markdown files and automatically shows the rendered readme.md files in each folder. This results in a much more usable help file than a simple .txt document. Storing this documentation in the code-base helps developers maintain the documentation. Anyone making a code change can easily open the .MD file in their source code editor or an online markdown editor, and immediately update the documentation. Thus the source-controlled Markdown files live next to, but not within, the code they support. It’s also somewhat more “zoomed out” than inline comments. These two factors result in a lower velocity of updates on this documentation. Because you can still include it in the same commits it changes with higher velocity than offline documentation. The final advantage of this format is that anyone who downloads the source code has immediate access to the implementation guides. Coupled with the inline documentation, this provides both maintainers and consumers with sufficient documentation. They can develop a basic understanding of the project without jumping into another system, such as a wiki. Wiki: where business meets development We use the wiki-level documentation to marry the implementation to the business requirements. This documentation consists primarily of requirements, enterprise architecture diagrams and considerations, and tactical diagrams such as unified modeling language (UML) flow charts and class diagrams. We also use pages (on the same wiki) as meeting minutes, and to record decisions. We use a wiki which has versioning so that we can see a complete history of how requirements and designs have changed over time. We thereby ensure a complete history of the requirements process and how it relates to the changing architecture. Incidentally, GitHub also provides a wiki feature, but we use a third-party wiki which integrates with our project management software. Release management: commit and pull request comments Our release management process includes code review. Our code review includes documentation review. As GitHub is our source control platform, we bake code review into our pull requests. The platform supports commenting upon check-in, inline comment threads on portions of commits, and a conversation thread on the pull request. The key to using these communication channels successfully is to ensure that all discussions result in a tangible output. Either clarify the code itself, or extend the permanent documentation in response to questions. If the reviewer doesn’t understand the code as it is written, future developers won’t either. Rewrite the code to be more self-explanatory, or extend the in-line or readme documentation. It’s not sufficient to end the conversation by replying to the thread: we treat this documentation as ephemeral, and on a long-lived code-base it’s a pain to review the full commit history. Bonus round: self-documenting code Finally, one quick plug for so-called “self-documenting code.” I’m a firm believer that the code should be self-explanatory at the surface. Explicit documentation should provide context or improve maintainability. There are already good articles about this (here’s one), so I won’t go into detail here. Final thoughts I hope that you learn from our experience. Our four-layer documentation architecture may not work for you, but it’s important to figure out what will. The big take-aways? First, it’s necessary to develop a healthy understanding of yourself and your own needs before you entangle yourself with a new code base. Second, it’s easier to stay out of a bad relationship with legacy code than to extract yourself once you’re already committed. And third, you only leave one legacy. But every commit you make contributes to it. They won’t all be good, they won’t all be bad, but they should at least be clear. Please think about what you’re leaving for those who come after you. Together we can reclaim our legacy as developers.

Development is about building solutions to solve problems. But when developing solutions, do you need to build everything yourself? In this episode we talk with Jonathan Solórzano-Hamilton (@jhsolor, @peachpie), Assistant Director of IT Operations and Architecture for ORIS at UCLA. We discuss why as a developer it is part of your job to know when not to build something yourself. During our conversation we outline when to use existing software and the benefits of doing so. We also outline guidelines to follow when looking for pre-existing solutions. Jonathan also provides a recap of his personal experience of what can happen when a development team tries to build everything in house. Key Takeaways Building everything yourself comes with risks and technical debt for you and your team. Focus your efforts on building whats important for your project, for everything else try and use expsing packages. It's part of your job to inform/sell your clients/company how to best build solutions. When looking for existing software Search for packages on reputable sources Look at community usage, is the package being used? check package activity, is it still supported? Review the license is it compatible with your project? Links from this Episode We fired our top talent. Best decision we ever made The Making of Tesla Completing the Netflix Cloud Migration Pervious Episodes Mentioned Using D.U.M.B goals and S.M.A.R.T goals to grow your development career. Taking Risks Have an idea for a future episode? Tweet Us: @devuppodcast Email Us: hello@developingup.com

A couple months ago, Jonathan Solórzano-Hamilton, a software architect at UCLA, wrote a Medium article called "We fired our top talent. Best decision we ever made." It's no surprise it took off - to many people, that makes no sense at all. But it struck a chord with me. I know that no matter how high performing someone is, if they are high drama, they can't stay. I got to chat with Jonathan last week and this is the result our amazing conversation. Enjoy!

Should we fire top talent if they are killing our workplace? What will it do to the rest of the team? Will it kill your business? Will it kill morale? Or will it be the best decision you ever made? We talk to software architect and technical collaboration leader at UCLA, Jonathan Solórzano-Hamilton. Jonathan wrote a blog post that took the world by storm where he told us of his experience in letting go the top talent and with that the toxic attitude that talent brought to the workplace. Links: https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde https://medium.freecodecamp.org/@peachpie

On today's episode we discuss "We fired our top talent. Best decision we ever made." An article from Jonathan Solórzano-Hamilton. We also talk about a response article titled "You fired your top talent. I hope you’re happy." from Tony Robinson. "He was working a 12 hour day by 7 day a week schedule which is absurd, That's not sustainable for anyone.” - Emma Castor, Software Engineer at Zeal Articles Featured: https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde https://medium.com/@deusexmachina667/you-fired-your-top-talent-i-hope-youre-happy-cf57c41183dd Additional reading: https://www.sciencealert.com/study-suggests-working-more-than-39-hours-a-week-is-bad-for-you Leave a review and get stickers! 1. Go to our page on ITunes and leave a review 2. Take a screenshot of your review and email it to podcast@codingzeal.com 3. If you're one of the first 100 people, we'll get your mailing address and send you your stickers! This podcast is brought to you by Zeal