Tech News - Application Development

Earlier this month, the team at Lazarus announced the release of Lazarus 2.0.0, an open-source cross-platform built with FPC 3.0.4 (Free Pascal Compiler). What’s new in Lazarus 2.0.0 LCL (Lazarus Component Library) Interface Changes ScreenToClient and ClientToScreen can now be calculated without scrollbar offset. Support for mouse wheel horz scrolling. This release comes with added flags to exclude support for some graphics formats to create smaller applications. The image list now supports multiple resolutions of one image. All the LCL controls now support High-DPI glyphs on Windows+Linux and Retina on Mac without any additional code. Every LCL control that supports ImageList now has a new ImagesWidth property for deciding what custom width at 96 PPI (100% scale) is to be used. IDE Changes This release includes several High-DPI IDE improvements and a retina support on Cocoa The IDE parses the custom compiler options for the fpc switch -FN<namespaces> for defining the default namespaces. Editor Lazarus 2.0.0 comes with "smart move cursor" moving commands for editor mappings. They are useful as an alternative for Ctrl+Left/+Right/+Shift+Left/+Shift+Right key. This release comes with added Goto/Toggle bookmark submenu for the toolbar. Additional options to fine-tune outline colors. Debugger This release comes with an added option "FixStackFrameForFpcAssert" to workaround fpc wrong frame pointer. There is an added option "FixIncorrectStepOver" to workaround "step over" issues experienced on some platforms. Components incompatibilities TSpinEditEx and TFloatSpinEditEx now inherit a common base class TSpinEditExBase. The reticule component is removed because the crosshair cursor is included in the more versatile charttools. To know more about this news, check out the Lazarus’ official post. Creating a Lazarus Component Microsoft joins the OpenChain Project to help define standards for open source software compliance Mapzen, an open-source mapping platform, joins the Linux Foundation project

Yesterday, GitHub launched a new feature named draft pull requests, which allows users to start a pull request before they are done implementing all the code changes. Users can start a conversation with their collaborators once the code is ready. If a user ends up closing the pull request for some reason or is refactoring the code entirely, the pull request would work in collaboration. Also, if a user wants to signal a pull request to be the start of the conversation and the code isn’t ready, users can still let the people check it out locally and get feedback. The draft pull requests feature can tag users if they are still working on a PR and notify the team once it’s ready. This feature will also help the pull requests that are prematurely closed, or for times when users start working on a new feature and forget to send a PR. When a user opens a pull request, a drop-down arrow appears next to the ‘Create pull request’ button. Users can toggle the drop-down arrow for creating a draft. A draft pull request is differently styled for indicating that it is in a draft state. Users can change the status to ‘Ready for review’ near the bottom of the pull request for removing the draft state and allow merging according to the project’s settings. In case a user has ‘CODEOWNERS file’ in their repository, a draft pull request will suppress notifications to those reviewers until it is marked as ready for review. Users have given mixed reviews to this news. According to a few users, this new feature will save up a lot of time. One of the users said, “It saves a lot of wasted effort by exploring the problem domain collaboratively before development begins.” While according to a few others this idea is not much effective. Another comment reads, “Someone suggested this on my team. I personally don’t like the idea because these policies often times lead to bureaucracy and then nothing getting released. It is not that I am against thinking ahead but if I have to in details explain everything I do, then more time is spent documenting than actually creating which is the part I enjoy.” To know more about this news, check out GitHub official post. Western Digital RISC-V SweRV Core is now on GitHub GitHub Octoverse: top machine learning packages, languages, and projects of 2018 Github wants to improve Open Source sustainability; invites maintainers to talk about their OSS challenges

Yesterday, Google announced the general availability of a new API for Google Docs that will help developers to automate their tasks that users manually do in the company’s online office suite. This API lets users read and write documents programmatically so that users can integrate data from various sources. Since Google Cloud Next 2018, this API has been in developer preview and is now available to all developers. This API lets users automate processes, create documentation in bulk and generate invoices or contracts. With this API, developers can set up processes that manipulate documents. It gives the ability to insert, move, delete, merge and format text, insert inline images and work with lists. Zapier, Netflix, Mailchimp and Final Draft are some of the companies that built solutions based on the new API during the preview period. Zapier integrated the Docs API into its workflow automation tool for helping users to create offer letters based on a template. Netflix used it to build an internal tool that allows its engineers to gather data and automate its documentation workflow. This API will help the users to regularly create similar documents with changing order numbers and line items based on information from third-party systems. The API’s import/export abilities help users for using the Docs for internal content management systems. Few users are happy with this news and excited to use the API. One of the users commented on HackerNews, “That is such great work. Getting the job done with the tools already around is just such a good feeling.” Whereas, few others think that it will take some time for Google to reach where Microsoft is now. Another comment reads, “They will have a lot of catchup to do to get where Office is now. I'm frankly amazed by how good Microsoft Flow has been.” Another user commented, “Microsoft Flow is a really powerful - in terms of advanced capabilities it offers.” To know more about this news, check out Google’s official post. Apple and Google slammed by Human Rights groups for hosting Absher, a Saudi app that tracks women Youtube promises to reduce recommendations of ‘conspiracy theory’. Ex-googler explains why this is a ‘historic victory’ Google’s Adiantum, a new encryption standard for lower-end phones and other smart devices

After Facebook, Twitter and Instagram,  Microsoft’s LinkedIn is getting into the league of video live streaming service by launching ‘LinkedIn Live’, this week, as reported by TechCrunch. This feature will allow people and organizations to broadcast real-time video to selected groups or the entire LinkedIn audience. Though, it’s still not clear when will LinkedIn make it possible for everyone to create LinkedIn live videos. LinkedIn Live will be rolled out to selected U.S. users via invite-only for the initial beta phase. Eventually, LinkedIn will also post a contact form for the users who want to apply for accessing this service. The initial live content that LinkedIn hopes to broadcast would include conferences, product announcements, Q&As and other events led by mentors and influencers, earnings calls, graduation and awards ceremonies, and more. LinkedIn is partnering with several third-party developers of live broadcasting streaming services including, Wirecast, Switcher Studio, Wowza Media Systems and more for creating and posting more polished live video on LinkedIn. Microsoft’s Azure cloud media product will be handling the encoding services for LinkedIn Live. The reason behind bringing LinkedIn Live LinkedIn introduced its first native video features in 2017 and within 17 months, LinkedIn has seen a boost in traffic and revenues from videos on its platform. Pete Davies, the director of product management at LinkedIn, said, “Video is the fastest growing format on our platform right now, and the one most likely to get people talking. Live video has been a big request—not least, I’d wager, because it is such a prominent part of how video is being used on other social platforms like YouTube, Facebook, and Twitter, putting the functionality front of mind.” Other than user requests, there might be more reasons to add this feature. The reasons could possibly be engagement and revenue generation. LinkedIn has generated revenue around videos via video advertising so far. During Microsoft’s last quarterly earnings, the company reported that revenues at LinkedIn were up 29 percent, with a reference to growing its ads business specifically. In a statement to TechCrunch, LinkedIn said, “Video ads earn 30 percent more comments per impression than non-video ads and that LinkedIn members spend almost three times more time watching video ads compared to time spent with static Sponsored Content.” As content is in the priority of LinkedIn Live, there are chances that the company might explore other ways of monetizing the content beyond ads. For instance, the company could charge viewers for unique experiences like conferences or for making certain Live events. It could also charge users for broadcasting content. LinkedIn might even launch Stories feature soon Last year, the company planned to work on implementing stories feature for the platform. The company plans to start off with “Student Voices” for university students in the U.S. This would allow students to post short videos to their Campus Playlist, which includes short 30-45 seconds videos made by college students. LinkedIn is possibly moving in the direction of rich content, with live streaming videos and stories the company might see a major benefit in terms of revenue and data. These live streaming videos will create an impact on the reach of the platform and also might help the platform’s premium subscription in near future. Tech jobs dominate LinkedIn’s most promising jobs in 2019 LinkedIn used email addresses of 18M non-members to buy targeted ads on Facebook, reveals a report by DPC, Ireland Creator-Side Optimization: How LinkedIn’s new feed model helps small creators    

This Wednesday, OpenChain announced that Microsoft has joined them as a platinum member and a board member to help drive open source compliance. Microsoft is a new addition to the list of many huge companies joining the OpenChain project including Uber, Google, and Facebook. OpenChain General Manager, Shane Coughlan announcing the collaboration said in a blog post, “We’re thrilled that Microsoft has joined the project and welcome their expertise. Microsoft is a strong addition not only in terms of open source but also in standardization. Their membership provides great balance to our community of enterprise, cloud, automotive and silicon companies, allowing us to ensure the standard is suitable for any size company across any industry.” Why Microsoft joined OpenChain? While building new products and services, companies make use of existing open source software provided by their supply chains. Working on these large-scale projects makes it difficult for them to ensure that the license requirements are met in a timely and effective manner. To make open source compliance simpler and more consistent for companies, the OpenChain Project develops standards and training materials. As a part of the OpenChain community, Microsoft will now work more closely with it to create future standards that will help bring even greater trust to the open source ecosystem. It has helped the OpenChain community in developing its upcoming OpenChain Specification version. David Rudin, Assistant General Counsel at Microsoft, said, “Trust is key to open source, and compliance with open source licenses is an important part of building that trust. By joining the OpenChain Project, we look forward to working alongside the community to define compliance standards that help build confidence in the open source ecosystem and supply chain.” Not only with  OpenChain, but Microsoft is also working with the Linux Foundation’s TODO Group, which is an open group of companies who collaborate to create practices, tools, and other ways for running open source programs. It also joined the Open Invention Network (OIN) last year in October and made its entire patent portfolio available to OIN members. Read the full announcement on OpenChain's website. Microsoft Cloud services’ DNS outage results in deleting several Microsoft Azure database records Microsoft announces Internet Explorer 10 will reach end-of-life by January 2020 Microsoft Office 365 now available on the Mac App Store

The January 2019 release of Visual Studio code v1.31 is now available. This update brings Tree UI improvements, updated to the main menu, no reload on extension installation and other changes. Features of Visual Studio code v1.31 No more reloads on installing extensions This was one of the most requested features in the VS community. Now you don’t have to reload VS code whenever you install a new extension. Reload is not needed even when you uninstall an unactivated extension. Improvements to the Tree UI There is a new tree widget based on the already existing list widget. This tree UI was adopted in File Explorer, all debug trees, search, and peek references. Tree UI brings features like: Better keyboard navigation for faster access Hierarchical select all in a tree starting from the inner node the cursor is on Customizable indentation for trees Expand/collapse all tree nodes recursively Horizontal scrolling Improvements to menus There are more navigation actions in the Go menu so that they can be discovered easily. The cut command is now available on the Explorer context menu. Changes in the Editor Text selection is smarter. Search history is shown below the search bar in the References view. Long descriptions can be written using string arrays. Semantic selection In HTML, CSS/LESS/SCSS, and JSON semantic selection is now available. Reflow support in integrated terminal The terminal will now automatically wrap and unwrap text whenever it’s resized. New input variable The input variables were introduced in the previous milestone. In Visual Studio code 1.31, there is a new input variable called command. It runs an arbitrary command when an input variable is interpolated. Updated extension API documentation The VS Code API documentation was rewritten and then moved to its own table of contents. For more details on the improvements in Visual Studio code 1.31 January 2019, visit the release notes. Code completion suggestions via IntelliCode comes to C++ in Visual Studio 2019 Microsoft Connect(); 2018 Azure updates: Azure Pipelines extension for Visual Studio Code, GitHub releases and much more! Neuron: An all-inclusive data science extension for Visual Studio

Last week, the team behind Electron announced that they will share the release timeline for Electron 5.0 and beyond publicly. For now, they have posted the schedule for Electron 5.0, which will include M72 and Node 12.0. Here’s the schedule the team has made public, which can still have some changes: Source: Electron The Electron team has been working towards making its release cycles faster and more stable. In December last year, they planned to release a new version of Electron in cadence with the new versions of its major components including Chromium, V8, and Node. They started working according to this plan and have seen some success. Source: Electron The team was able to release last two versions of Electron (3.0 and 4.0) almost parallelly with Chromium’s latest versions. To keep up with Chromium releases, the two versions were released with a 2-3 month timeline for each release. They will be continuing this pattern for Electron 5.0 and beyond. So, for now, developers can expect a major Electron release approximately every quarter. Read the timeline shared by the Electron team on their official website. Flutter challenges Electron, soon to release a desktop client to accelerate mobile development Electron 3.0.0 releases with experimental textfield, and button APIs Electron Fiddle: A ‘code playground’ for experimenting with cross-platform native apps

Red Hat has come out with a new Integrated development environment (IDE), called CodeReady Workspaces. The new IDE, announced yesterday, is a Kubernetes-native, browser-based environment for developers to enable easier collaboration among the development team. CodeReady Workspaces is based on the open source Eclipse Che integrated development environment (IDE) project and has been optimized for Red Hat OpenShift and Red Hat Enterprise Linux. It offers the enterprise development teams a shareable developer environment, which comprises the tools and dependencies required to code, build, test, run and debug the container-based applications. Other than that, it is the first Kubernetes-native IDE in the market that runs inside a Kubernetes cluster and is capable of managing the developer’s code, and dependencies present inside OpenShift pods and containers. Also, there is no need for the developers to be Kubernetes or OpenShift experts in order to use the IDE. Additionally, Red Hat CodeReady Workspaces comes with a sharing feature called Factories, which is a template containing the source code location, runtime, tooling configuration and commands that are needed for a project. It enables development teams to run the new Kubernetes-native developer environment in a few minutes. Team members can access their own or shared workspaces on any device with a browser and on any IDE and operating system (OS). According to the Red Hat team, CodeReady Workspaces is an ideal platform for DevOps based organizations and allows the IT or development teams to manage workspaces at scale and effectively control system performance, security features and functionality. CodeReady Workspaces allows the developers to: Integrate their preferred version control (public and private repositories). Control workspace permissions and resourcing Make use of Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) authentication for single sign-on. “Red Hat CodeReady Workspaces offers enterprise development teams a collaborative and scalable platform that can enable developers to more efficiently and effectively deliver new applications for Kubernetes and collaborate on container-native applications”, said Brad Micklea, senior director, Developer Experience and Programs, Red Hat. Red Hat CodeReady Workspaces is free with an OpenShift subscription. You can download it by joining the Red Hat Developer Program. For more information, check out the official Red Hat CodeReady Workspaces blog. Red Hat drops MongoDB over concerns related to its Server Side Public License (SSPL) Red Hat acquires Israeli multi-cloud storage software company, NooBaa Red Hat announces full support for Clang/LLVM, Go, and Rust

RustPython is an open-source Python 3 interpreter written in Rust with the whole Python 3 implementation completely done in Rust. This interpreter is currently in the early stages and the documentation is also being developed. You need wasm-pack and npm to install it. You can test it by using the following code: $ git clone https://github.com/RustPython/RustPython $ cd RustPython $ cargo run demo.py Hello, RustPython! The code style used is rustfmt. You can also test with cargo on the interactive shell.You can run only basic examples as currently there is only preliminary support for WebAssembly. Using a memory safe language like Rust instead of C or C++ has benefits as pointed out by a Hacker new user: “At least 1/3 of Python's CVEs could have been prevented by using a memory safe language like Rust.” Another user said: “This is wonderful. This could become the best way to move Python projects to Rust: initially just run on the RustPython interpreter, but then optimize low-level routines in Rust. In 15 years I wouldn't be surprised if this or something like it surpasses CPython in popularity.” For more details and installation instructions visit the GitHub repository. Rust 1.32 released with a print debugger and other changes EuroPython Society announces the ‘Guido van Rossum Core Developer Grant’ program to honor Python core developers Python governance vote results are here: The steering council model is the winner

This Tuesday, Microsoft announced .NET Core 3 Preview 2 with new features in .NET Core 3 and C# 8. C# 8 The eighth iteration of C# is a major release and includes many new features. Declarations Statements don’t need to be indented now. Switch expressions C# 8 comes with switch expressions in which you can use the new syntax. Terser syntax returns a value as it is an expression. It’s fully integrated with pattern matching. Async streams The compiler and framework libraries should match correctly for async streams to work. You will need .NET Core 3.0 Preview 2 and Visual Studio 2019 Preview 2. Alternatively, you can also use the C# extension for Visual Studio Code. Floating point improvements in IEEE The goal is to expose all operations that are needed and they are behaviorally compliant with the IEEE spec. A fast in-box JSON Writer & JSON document Two new objects were added—System.Text.Json.Utf8JsonWriter and System.Text.Json.JsonDocument. Utf8JsonWriter The Utf8JsonWriter enables a high-performance, non-cached way to write UTF-8 encoded JSON text from common .NET types. JsonDocument System.Text.Json.JsonDocument is also added built on top of the Utf8JsonReader. JsonDocument provides enables parsing JSON data and builds a read-only Document Object Model (DOM). It can be queried to support enumeration and random access. Assembly Unloadability Assembly unloadability is a new ability of AssemblyLoaderContext. It is transparent and exposed with only a few new APIs. A loader context to be unloaded with this. This releases all of the memory for static fields, instantiated types, and the assembly itself. Visual Studio support Using .NET Core 3 for development requires using Visual Studio 2019. WPF and Windows Forms templates were added to the New Project Dialog for easier access via the command line. These were a select few updates from the new .NET Core 3 Preview 2, for a complete list of changes, visit the Microsoft Blog. Microsoft Connect(); 2018: .NET foundation open membership, .NET Core 2.2, .NET Core 3 Preview 1 released, WPF, WinUI, Windows forms open sourced What to expect in ASP.NET Core 3.0 .NET Core 3.0 and .NET Framework 4.8 more details announced

On Monday, the team at Anaconda released a new version of Conda, an open source package management and environment management system that runs on Windows, macOS, and Linux. Conda 4.6.0 comes with support for more shells, better interoperability, improved Conda search and more. https://twitter.com/anacondainc/status/1089970114143965185 What’s new in Conda 4.6.0 Support for more shells Conda 4.6.0 comes with extensive initialization support so that more shells can use the conda activate command. It also comes with added support for PowerShell. This release comes with “conda init” functionality which gets Conda working quickly and less disruptively on a wide variety of shells such as zsh, bash, csh, fish, xonsh, and more. Improving interoperability with pip Conda 4.6.0 comes with added preview support for better interoperability. This release uses pip-installed packages to satisfy dependencies. It is possible to remove pip-installed software and replace them with Conda packages when appropriate.   Note: This feature is disabled by default right now because it can significantly impact Conda’s performance.  If you’d like to try it, you can set this condarc setting: conda config --set pip_interop_enabled True Activation of a single environment This release provides an ideal situation where a single environment can be active at any given time. Conda search gets better License and license_family have been added to MatchSpec for conda search. Enhanced fish shell This release features autocompletion for conda env to the fish shell. Major improvements This release comes with clean output for conda <COMMAND> --help and conda config --describe. In Conda 4.6.0, https://repo.anaconda.com/pkgs/pro has been removed from the default value for defaults. Reference to 'system' channel has been removed from this release. This release comes with http error body to debug information. Creating env name with space is no more supported. This release supports MatchSpec syntax in environment.yml files. With this release, the name of 'condacmd' dir has been changed to 'condabin'. It is now possible to disable timestamp prioritization when not needed. In this release, repodata has been cached as UTF-8 for handling unicode characters. Performance of Conda 4.6.0 has been improved to cache hash value on PackageRecord Major Changes In this release, 'conda env attach' and 'conda env upload' have been removed. This release comes with deprecation warnings for 'conda.cli.activate', 'conda.compat', and 'conda.install'. Env name with colon is now supported. In Conda 4.6.0, the default value of max_shlvl has been changed to 0. Non-user facing changes With OO inheritance, activate.py has been cleaned up. The pep8 project has been renamed to pycodestyle. This release comes with copyright headers. Bug fixes In the previous releases, the verify step of conda used to hang for a long time while installing a corrupted package. This has been fixed. In this release, the progress bar uses stderr instead of stdout. It is now possible to pin a list of packages by adding a file named ‘pinned’ to the conda-meta directory with a list of the packages that the user don’t want to update. To know more about Conda 4.6.0, check out the official announcement. Anaconda 5.3.0 released, takes advantage of Python’s Speed and feature improvements Share projects and environment on Anaconda cloud [Tutorial] Visualizing data in R and Python using Anaconda [Tutorial]  

The developer community surely owes respect to the innovation of ‘View Source’ as it had made things much easier for the coders. Well, David Heinemeier Hansson, the developer of Ruby on Rails have made a move to make programmers’ life easy by announcing that Rails 6 will be shipping source maps by default in production. Source maps help developers view code as it was written by the creator with comments, understandable variable names, and all the other help that makes it possible for programmers to understand the code. It is sent to users over the wire when users have the dev tools open in their browser. Source maps, so far, have been seen merely as a local development tool and not something that will be shipped to production. Live debugging would make things easier for the developers. According to the post by David Heinemeier Hansson, all the JavaScript that runs Basecamp 3 under Webpack now has source maps. David Heinemeier Hansson said, “We’re still looking into what it’ll take to get source maps for the parts that were written for the asset pipeline using Sprockets, but all our Stimulus controllers are compiled and bundled using Webpack, and now they’re easy to read and learn from.” David Heinemeier Hansson is also a partner at the web-based software development firm Basecamp. He said that 90% of all the code that runs Basecamp, is open source in the form of Ruby on Rails, Turbolinks, Stimulus. He further added, “I like to think of Basecamp as a teaching hospital. The care of our users is our first priority, but it’s not the only one. We also take care of the staff running the place, and we try to teach and spread everything we learn. Pledging to protect View Source fits right in with that.” Sam Saffron, the co-founder at Discourse said, “I just wanted to voice my support for bringing this back by @dhh . We have been using source maps at Discourse now for 4 or so years, including maps for both JS and SCSS in production, default on.” According to him one of the important reasons to enable source maps in production is that often JS frameworks have "production" and "development" modes. Sam Saffron said, “I have seen many cases over the years where a particular issue only happens in production and does not happen in development. Being able to debug properly in production is a huge life saver. Source maps are not the panacea as they still have some limitations around local var unmangling and other edge cases, but they are 100 times better than working through obfuscated minified code with magic formatting enabled.” According to Sam, there is one performance concern that is the cost of precompilation. The cost was minimal at Discourse but the cost for a large number of source maps is unpredictable. Users had discussed this issue on the GitHub thread, two years ago. According to most of them the precompile build times will be reduced. A user commented on Github, “well-generated source maps can actually make it very easy to rip off someone else's source.” Another comment reads, “Source maps are super useful for error reporting, as well as for analyzing bundle size from dependencies. Whether one chooses to deploy them or not is their choice, but producing them is useful.” Ruby on Rails 6.0 Beta 1 brings new frameworks, multiple DBs, and parallel testing GitHub addresses technical debt, now runs on Rails 5.2.1 Introducing Web Application Development in Rails

Last week, the team at Google asked the Supreme Court of the United States to review their copyright dispute with Oracle over the use of software interfaces. Unless the Supreme Court interferes, the industry will be stuck by the court’s decision, which states that the software interfaces used in creating new programs are not allowed under copyright law. Software interfaces let computer programs interact with each other and push innovations by letting developers build technologies for different platforms. This is going to have a great impact on innovation across the computer industry. Voices from business, technology, academia, and the nonprofit sector have spoken out about the devastating impacts of this case. The questions raised by Google to the Supreme Court are as follows: Whether copyright protection extends to a software interface? Whether, as the jury found, petitioner’s use of a software interface in the context of creating a new computer program constitutes fair use? Google writes, “We support software developers’ ability to develop the applications we all have come to use every day, and we hope that the Supreme Court will give this case the serious and careful consideration it deserves.”   According to the petition, “the Federal Circuit concluded that the merger doctrine does not restrict copyright protection for computer code necessary for interoperability as long as the original author could have written the code in more than one way.” In 2008, Android was released and it helped developers overcome the challenges of limited memory, smaller processors, and short battery life. Android was built by following the practice of reusing software interfaces which provide sets of commands that make it easy to implement common functionality. Android came with a transformative platform while letting Java programmers use their existing skills to create new applications. The team at Sun Microsystems was happy with the release of Android and said, “It had strapped another set of rockets to the [Java] community’s momentum.” After acquiring Java in 2010, Oracle sued Google for using the software interfaces. Oracle’s lawsuit for the right to control software interfaces might affect the community of developers who have invested in learning the free and open Java language. Initially, a court ruled that the software interfaces, in this case, are not copyrightable, but that decision got overruled. A unanimous jury then pointed out that Google’s use of the interfaces was a legal fair use, but that decision got overruled. According to the official blog post by Google, the U.S. Constitution has authorized copyrights to “promote the progress of science and useful arts,” not to impede creativity or promote lock-in of software platforms. The petition reads, “Under Section 102(b), copyright protection does not extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such [original] work.” Though according to a blog post by Electronic Frontier Foundation, EFF is in the support of Google and will be supporting the company’s petition. Even in May 2013, EFF filed an amicus brief on behalf of many computer scientists to Federal Circuit with the opinion that APIs should not be subject to copyright. This news has become a matter concern for many. In a statement to Ars, James Grimmelmann, a copyright scholar at Cornell University and former software developer, said, "The Federal Circuit's decision threatens the continued vitality of software innovation." It seems even CCIA (Computer and Communications Industry Association) is in support of Google. CCIA writes, "It is hard to see why programmers who have learned the Java APIs should remain captives of Oracle because of an investment in learning made by the programmers and not by Oracle." Users are agitated by this news and they are not welcoming the idea of restricting the use of interfaces. This news has created a lot of buzz in the developer communities and most of the developers are worried. One of the comments on HackerNews reads, “A reminder that what the law says, and what is a good idea, is not necessarily the same thing. The courts rule on the first point. Given that Oracle has prevailed in court on this before, one has to at least entertain the possibility that our law really allows for API to be copyrighted.” Another comment reads, “If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few rent seekers profiting.” Few users are with this new move. A comment reads, “It was not ... intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason.) It was not transformative in the sense of a new platform either, since other Java smartphones predated Android.” Some of the users are with the court and think this battle is about what’s legal and illegal. Another comment reads, “What I'm saying is that all the people who are trying to make the "but it's bad!" argument are missing the point of the courts. Courts are not there to determine whether it's good or bad, only whether it's legal or illegal.” According to some users, Google could have called its resizable array as android.data.ResizableArray<E> but it named it java.util.ArrayList<E> and also copied the method signatures. But the matter of concern for the developers is what if other companies also end up filing such cases. And what if Google is the next one to do so? One of the users commented, “Does anyone believe Google will not be doing the exact same thing with its (moribund) technologies in, say, 5-10 years?” To know more, check out Google’s blog post. Why Google kills its own products Google and Ellen MacArthur Foundation with support from McKinsey & Company talk about the impact of Artificial Intelligence on circular economy Google is secretly urging National Labor Relations Board to overturn protection for activist workers, Bloomberg reports

Apple announced Swift 5 for their Xcode 10.2 compiler. Swift in Xcode 10.2 beta brings a couple of new features like smaller app sizes when testing, new library, compiler features, and more. The application binary interface (ABI) is stable in Swift 5. Smaller app size App sizes on Swift 5 in Xcode 10.2 beta can be smaller now when deployed for testing. This is true when using TestFlight or when thinning an app for local distribution. Smaller app sizes are possible as Swift apps don’t include dynamically linked libraries for the Swift standard library anymore. Moreover, Swift SDK overlays for devices running iOS 12.2, watchOS 5.2, and tvOS 12.2. Apple calls this concept ‘App thinning’. New features in Swift 5 A new attribute named @dynamicCallable allows dynamic language interoperability. Key paths support the identity keypath \.self. You can no longer write functions that take variadic arguments. Now you can change the enumeration case to ‘take an array explicitly and pass an array in.’ A try? block with an Optional type does not return a nested optional, instead of flattening the resulting option Literal types are modified so that expressions don’t overflow the default integer literal where the type is Int. String interpolation is now simpler, has better performance and efficiency. Changes in the Swift standard library The DictionaryLiteral type is now KeyValuePairs Swift strings bridged into Objective-C code can now return a non-nil value in certain cases The Sequence protocol is now disassociated from SubSequence. Native encoding in the string structure is now UTF-8 instead of UTF-16. What’s new in Swift package manager? When using Swift 5, targets can now declare commonly used build settings that are target-specific. In the Swift 5 Package.swift tools-version, packages can customize minimum deployment target settings. Top level packages can override dependency URLs The --enable-code-coverage flag helps other tools to use code coverage data generated by a tool Support for Swift 3 Package.swift tools-version has been dropped Larger packages are handled better by the package manager Package resolution for incompatible dependency versions are forced to fail A new --repl option in swift run launches the Swift REPL. This supports importing library targets of a package. Swift compiler Exclusive memory access is imposed at runtime by default. Swift 3 is removed. In Swift 5, switches on enumerations declared in Objective-C/system frameworks have to handle unknown cases For Swift modules, default arguments are printed in SourceKit-generated interfaces Support for Optional types is now added in unowned and unowned(unsafe) variables To know more details and bug fixes, visit the release notes. Swift is now available on Fedora 28 ABI stability may finally come in Swift 5.0 Swift 4.2 releases with language, library and package manager updates!

Yesterday, Maël Nison, maintainer at Yarn, opened a GitHub thread on the Yarn repository describing the roadmap for the next major Yarn release. The roadmap (codenamed Berry) contains significant changes that are planned for Yarn's design. Nison reinstates that Yarn’s philosophy will continue to be the same based around three important principles. Developing Javascript projects in Yarn should have totally predictable and reproducible behavior. Developing Javascript projects should be easy. Contributing to the Yarn ecosystem should be simple. Long-term and Short-term goals for Yarn in 2019 Yarn will be rewritten in TypeScript. The entire codebase will be ported from Flow to TypeScript. This is done to help third-party contributors to help to maintain Yarn. Yarn will become a development-first tool. This means Package managers will no longer work as tools for running on your production servers. Yarn will become an API first and CLI second. Its internal components will be split into modular entities Yarn will be designed in a way that each component of Yarn’s pipeline can be switched to adapt to different install targets. Yarn will now be a package manager platform as much as a package manager. Overall compatibility will be preserved when possible. The caveat: installs will now use Plug'n'Play by default. Major changes and new features The lockfile format will become a strict subset of YAML. Yarn will drop support for both Node 4 and Node 6. The log system will be renovated with implementation of diagnostic error codes from Typescript. Some features currently in the core will be moved into contrib plugins. The cache file format will switch from Tar to Zip, which offer better features in terms of random access. Nested workspaces will be supported out of the box. Running Yarn ./packages/my-package add foo will run Yarn add foo into my-package. There will be a new resolution protocol, workspaces:, which allows developers to force the package manager to link one of the packages against a workspace. Yarn constraints is a new command which will allow developers to enforce constraints across workspaces. The Yarn link command will now persist its changes into the package.json files Berry will ship with a portable posix-like light shell that'll be used by default. Scripts will be able to put their arguments anywhere in the command-line (and repeat them if needed) using $@. Cache will become fully atomic, with multiple Yarn instances running concurrently on the same cache without risking corrupting the data. Developers are generally positive about this release specially pointing out the change of moving from Flow to Typescript. A hacker news user states, “Finally one of the biggest news is the switch from Flow to Typescript. I think it's now clear that Facebook is admitting defeat with Flow; it brought a lot of good in the scene but Typescript is a lot more popular and gets overall much better support. Uniting the JS ecosystem around Typescript will be such a big deal.” Another comment reads, “The codebase will be ported from Flow to TypeScript. We hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript.” A new repository will be set up in early February. Post which Berry will be accessible by running yarn policies set-version berry within a project. Hadoop 3.2.0 released with support for node attributes in YARN, Hadoop submarine and more Starting with YARN Basics Introducing ReX.js v1.0.0 a companion library for RegEx written in TypeScript