Month: January 2017

Ui Router Ng2 1.0.0 Beta.4

Today’s 1.0.0-beta.4 release of ui-router-ng2 brings support for Ahead of Time compilation (AoT),
support for @ngtools/webpack lazy loading,
and much better integration with the Angular CLI.

This release includes more breaking changes than usual.
We are making an effort to call out more breaking changes that could potentially
break end user applications, even if the prior behavior was unspecified.

Changes in 1.0.0-beta.4

The 1.0.0-beta.4 is a major update, which includes many bug fixes and lots of new features.

Please see the release notes
for detailed information, including the BREAKING CHANGES.

Repository split

During the 1.0 alpha phase, we made the UI-Router core agnostic to AngularJS.
This enabled us to continue development of
angular-ui-router
while creating
ui-router-ng2
and
ui-router-react.
The ui-router-ng2 code augments the
ui-router-core
code adding Angular (2+) specific features and concepts, as well as integrating with the Angular lifecycle and DI system.

During the betas, both ui-router-ng2 and the angular-ui-router for ng1 were built from the same repository.
This seemed like a good idea at the time because it allowed PRs to a monolithic repository.
However, over time it became apparent that hosting both codebases together was not sustainable.
So, we split the repositories into:

  • http://github.com/ui-router/ng2: ui-router-ng2: UI-Router for Angular (2.0 and above)
  • http://github.com/ui-router/core: ui-router-core: UI-Router core
  • http://github.com/angular-ui/ui-router: angular-ui-router: UI-Router for AngularJS 1

This release of ui-router-ng2 is the first one built from the modular UI-Router repositories.
Going forward, the release schedules for AngularJS and Angular (2+) will no longer coincide.

For those of you using the ng1-to-ng2 hybrid adapter, stay tuned.
We will be changing the approach of the hybrid adapter to accomodate the different release cycles
of the AngularJS and 2+ codebases.

Angular CLI

Many users have been asking when we would support the Angular CLI and support Ahead of Time compilation.
Finally, ui-router-ng2 has full AoT support, and integrates nicely with the Angular CLI including AoT and Lazy Loading.

To use the Angular CLI and lazy loading, follow this pattern:

Add npm dependency to ui-router

Add ui-router-ng2 (and temporarily also add @angular/router):

npm install --save ui-router-ng2@1.0.0-beta.4 @angular/router

Add UIRouter to the root module

Add UIRouterModule.forRoot to the root NgModule’s imports in app.module.ts

export let ROOT_STATES = [];
export function routerConfigFn(router: UIRouter, injector: Injector) {
  // ... do router config
}
imports: [
    UIRouterModule.forRoot({
        states: ROOT_STATES,
        useHash: false,
        otherwise: "/home",
        config: routerConfigFn
    })
...

Generate a child NgModule

Use the CLI to generate a child module.
This is a nested NgModule which will be lazy loaded.

ng generate module admin

Create a top-level state as a Future State

A future state is a placeholder for a state that will be defined by a lazy loaded NgModule.
Define the future state in the parent module.
Append .** to the future state’s name, and supply a loadChildren string which points to the lazy NgModule.

In app.module.ts:

export let ROOT_STATES = [
    { 
      name: 'admin.**',
      url: '/admin', 
      loadChildren: './admin/admin.module#AdminModule'
    }
]

Create the final state in the child NgModule

When the child module is lazy loaded, it should fully define the state to replace the Future State placeholder.

In /admin/admin.module.ts:

export const ADMIN_STATES = [
  { name: 'admin', url: '/admin', component: AdminComponent }
]
@NgModule({
  imports: [ 
    UIRouterModule.forChild({ states: ADMIN_STATES });
  ],
  declarations: [ AdminComponent ],
})
export class AdminModule {}

Serve the app

You can now serve or build the app using angular-cli in either AoT mode or JIT mode.

ng serve -aot
ng build -aot --prod --sourcemap

Problems/Feedback?

If you have feedback or problems integrating ui-router-ng2 with angular-cli, please create an issue
in the ui-router-ng2 repo.

Open Hub in 2017

Hail Hubbites!

We’d love to share some of the things that have been going on and will be going on here in Open Hub Land. We accomplished some very significant work in 2016 and would like to take a moment to lay it out and then talk about what we’d like to accomplish in 2017.

2016 Review

Please recall from our 2016 Review what we did in 2015: rebuilt the UI, addressed spam account creation, improved back-end performance (5X in some cases), started inventing new security data features. The plan for 2016 was to create a new Project Vulnerability Report and Project Security Pages, run the Spammer Cleanup Program, virtualize the back end (the FISbot project), switch to Ohcount4J, connect to other sites related to OSS.  Here’s how we did:

  • Invented the Project Vulnerability Report algorithms and presentations
  • Prototyped Project Security Pages with the (now closed) security.openhub.net pages
  • Deployed FISbots and Ohloh Analysis onto virtual servers (this involved migration some 10TB of OSS project data from multiple servers to a single SAN)
  • Started running batches of accounts through the Spammer Cleanup Program.  To date, we’ve cleared out some 350,000 spam accounts (YAY!!)
  • Design and implemented a Prototype Project Security Page to report known vulnerabilities in OSS projects.  Collected user feedback from that experiment
  • Explored using Ohcount4J instead of Ohcount.  Decided to stay with Ohcount.
  • Added a feature to add an entire GitHub account to a single Open Hub project
  • Numerous back end improvements and defect resolutions to consistently delivery web pages under 200 ms (6X faster than 2015 on average)
  • Defended against a number of malicious attacks against our API service and web site (comes with the territory of running a non-trivial web application, amirite?)

There’s more though!

The FISbot was implemented as a stop gap measure to address issues we had with the back end bare metal crawlers. We were waiting for another project to provide a central set of Fetch, Import, and SLOC services to the Black Duck enterprise. The plan was to shut down the FISbots and use this other service.  However, after deploying our FISbots, it was decided that we should expand the FISbot to handle the additional enterprise scenarios.  So, completely unplanned at the beginning of the year, we implemented the eFISbot Project, which we also delivered last year.

Last point: as we talked about in Detail on the Infrastructure post, the migration of that 10TB collection of OSS project data onto the production server ran into serious issues that forced us to re-fetch every one of the nearly 600K code locations we monitor.  This was a serious multi-month disruption, from which we have mostly entirely recovered.  We have re-fetched all the repositories, but there are lingering issues in getting all those repositories and corresponding projects refreshed in the 24 – 72 hour window we’ve set for ourselves.

So, in summary, we’ll add to our 2016 Review:

  • Implemented and delivered eFISbot
  • Survived the treacherous NFS SNAFU and the Great Code Location ReFetch

I feel it is also important that we mention again the passing of our friend and colleague Pugalraj Inbasekaran in February. I still feel his absence as an ache near my heart and miss him.

2017 Plan

We have a few main focuses for 2017

  1. Make the back end screamingly fast
  2. Make it wicked easy to add projects from GitHub to the Open Hub and get data from the Open Hub into your GitHub pages
  3. Continue the UI update with wider pages and more responsive layouts
  4. Add new languages to Ohcount

For that back end, we’ve been given permission to obtain a new set of servers.  Currently, the Open Hub runs off a single database (we’ve talked about that over and over again).  We’ve put in a purchase request for 2 database servers that have over 4X the CPU cores and 9X the RAM. One server will be the master and the other the replicate. These servers will support only Fetch, Import, SLOC and Analysis operations (write intensive) so, we’re calling this the FISA DB.  The current database will remain with the purpose of only presenting generated analysis (read intensive) through the Ohloh-UI application, so that will be the UI DB.  We are SO VERY EXCITED!!! SQUEEEEEE!!! Ah. Sorry; sorry. Please excuse the author (but it’s SOO exciting!)

As always, thank you so very much for being part of the Open Source Software community and your continued support of the Open Hub.

Angular Ui Router 1.0.0 Rc.1

We released Angular UI-Router 1.0.0-rc.1 today.
This release indicates that the APIs are not expected to change before the final release of ui-router 1.0.

This release includes more breaking changes than usual.
We are making an effort to call out more breaking changes that could potentially break end user applications, even if the prior behavior was unspecified.

Changes in RC.1

RC.1 is a major update, which includes many bug fixes and lots of new features.

Please see the release notes for detailed information, including the breaking changes.

Repository split

During the 1.0 alpha phase, we made the UI-Router core agnostic to AngularJS.
This enabled us to create
ui-router-ng2 and
ui-router-react
by augmenting the
ui-router-core
code.

During the betas, both ui-router-ng2 and the angular-ui-router for ng1 code were built from the same repository.
This seemed like a good idea at the time because it allowed PRs to a monolithic repository.
However, over time it became apparent that hosting both codebases together was not sustainable.
So, we split the repositories into:

  • http://github.com/angular-ui/ui-router: angular-ui-router: UI-Router for AngularJS 1
  • http://github.com/ui-router/ng2: ui-router-ng2: UI-Router for Angular (2.0 and above)
  • http://github.com/ui-router/core: ui-router-core: UI-Router core

This release is the first one built from the modular UI-Router repositories.

This release (1.0.0-rc.1) of Angular UI-Router is not accompanied by a release of UI-Router for Angular (2+)+.
Going forward, the release schedules for AngularJS and Angular (2+) will no longer coincide.

Upgrading

If you haven’t considered upgrading to UI-Router 1.0, now is the time to start planning.
There are some breaking changes listed, but the should be fairly minimal for the typical UI-Router application.
Please follow the migration guide when upgrading.

Implement an HTTP to HTTPS redirect

Implement an HTTP to HTTPS redirect

If you’re looking to implement an HTTP to HTTPS (SSL) redirect for your web application, you can now enable a feature directly on the load balancer instead of configuring it on your server. This significantly improves redirect performance and reduces the load on your servers.

To implement this change, you must be on the main page of your Load Balancer or Web Application Firewall configuration page, as shown in the sample image below. Then click the “options” pop-up beside the HTTP protocol (this feature is only available in the HTTP protocol, not TCP etc.). If you haven’t created this protocol yet, you’ll need to, plus once implemented, you’ll need to map it to your server’s private port and IP too.

http to https options dialog

Once the options window opens, you will see the HTTP to HTTPS redirect checkbox as shown below. Simply check it and save.

HTTP to HTTPS redirect

After saving, allow a few minutes for the change to propagate our network before testing.

The post Implement an HTTP to HTTPS redirect appeared first on Total Uptime®.

How to block specific countries from reaching your website or application

How to block specific countries from reaching your website or application

Total Uptime’s Cloud Load Balancer and Web Application Firewall support a feature to block entire countries from reaching  your website or application on a per-port basis. This is a powerful tool to stop unwanted traffic from getting anywhere near your servers or devices. When enabled, traffic that reaches our network will have the origin IP checked against the popular MaxMind GEO database. If the client/origin IP matches the country you’ve blocked, the user’s connection will be dropped.

To implement this feature, you must click on the config/pack from the left navigation in the Configuration Builder. This will bring you to the main screen of your config as shown below:

TLS editing step 1

Once there, you can now select the Options button (as shown above) for the port you wish to block traffic on. When you click on the options dialog, you will see a new window as shown below:

block countries

Now, simply select the countries you wish to block by using the right arrow to move them into the Blocked Countries box. When finished, click the Save & Close button to push the changes to our network. Within a few minutes, the change will take effect.

Don’t forget!  This setting is done on a per-port basis. So if you have more than one port you wish to block, you will need to do this for all of them.

NOTE: This feature is not supported with all protocols. HTTP, SSL, SSL_BRIDGE, TCP (and a few others), no problem! But it is not available with UDP, DNS and a couple others.

The post How to block specific countries from reaching your website or application appeared first on Total Uptime®.