I've built myself a small Sencha Touch 2 app, so now i'm trying to make it smaller/minify it
My app looks like
/touch
/app.js
/resources
/ux
/app
/app.json
/index.html
/build.xml
So I was trying to make it more efficient & faster to load so I loaded up Sencha Cmd and ran
sencha compile --classpath=app,touch/src,ux include -all
So it does what looks like compiling it, without giving any errors, it gives a few warnings but those are ok. So it finishes up and nothings changed. The directories are exactly as there were before.
How would I use this correctly to make my app smaller & load faster?
The command
sencha app build package
or
sencha app build production
Will minify/package your application. All of the javascript will be contained in a single app.js file, and the javascript+css will be minified. More information about these commands can be found here: http://docs.sencha.com/touch/2-1/#!/guide/command_app
See Also cmd tool doc for detailed info:
http://docs.sencha.com/cmd/3.1.2/#!/guide/command_app_touch-section-deploying-your-application
Deploying your application simply means editing source code and refreshing the browser. All source files are dynamically loaded on demand. There's no building process involved. When it comes to deployment, Sencha Cmd provides the following four build environment options:
testing - intended for QA prior to production. All JavaScript and CSS source files are bundled, but not minified, which makes it easier to debug.
package - creates a self-contained, redistributable production build that normally runs from the local file system without a web server.
production - creates a production build that is normally hosted on a web server and serves multiple clients (devices). The build is offline-capable using HTML 5 application cache, and is enabled to perform over-the-air updates.
native - first generates a package build, then packages it as a native application, ready to be deployed to native platforms.
Related
I have vue project which published on Digital Ocean. The main problem is when i make some changes on FileZilla it is not affect on website. How can i solve this issue?
This is not an issue per-se. This is just the way how modern web development works. Vue.js (but also Nuxt) is using a bundler right now (Webpack, Vite are the most common), hence to go to production it needs to be bundled each time you push something to it.
If you upload something via FTP or SSH and edit some source code, a bundle step will be required in order to get any changes on the actual webapp.
Backend languages may not need that, for example you could SSH into a server and change some .php file, if you F5 the page it will be updated in real time. But this is not how frontend JS code works, it needs to be optimised.
Another thing, sending code via SSH/FTP is not really a good workflow because it is not easily trackable, no version-controlled, will not trigger any build flags in case of an error etc...
The best approach is to have a git repo + some build step included in some CI.
A common platform for it is Netlify, you connect a Github repo, you tell which command to use to build the project and each time you push some code, it may do some checks/tests/optimizations/etc... via Github Actions before being released automatically to production (updated on your webapp).
This workflow have a lot of benefits as one may tell but is also de-facto, the official/regular approach for modern Web development on the frontend.
Environment: Ubuntu 16.04, .NET Core 1.10 (1.0.0-preview2-1-003177), Visual Studio Code 1.8.1
I just generated a new ASP.NET Core app. When I run the app from a terminal window, the start up web page gets displayed as expected.
$ cd MyApp
$ dotnet run
However, the web page is slightly different when I load MyApp folder from VSC and press F5 to debug it. Specifically, the default top toolbar is missing. Toolbar items such as Home, About, Contact, etc. line up in a single column.
I have compared the generated html between the two. When run from the command line, the stylesheet links are:
href="https://ajax.aspnetcdn.com/ajax/bootstrap/3.3.6/css/bootstrap.min.css"
href="/css/site.min.css"
When run from VCS, the links are:
href="/lib/bootstrap/dist/css/bootstrap.css"
href="/css/site.css"
On examining local file structure, I see file css/site.css is present under folder wwwroot. However, I don't see any lib folder at all.
More information. Turns out _Layout.cshtml adds links based on environment names. When the names are Staging and Production, the generated bootstrap link is for ajax.aspnetcdn.com. For "Development," the link is "/lib/xxx."
Wondering how I force VCS to automatically populate bootstrap.css into lib directory.
Problem solved. When the website is generated, a file, bower.json, is created. This file has information about the bootstrap package. However, for some reason, this package is not automatically downloaded. You need to do the following:
From VSC, install the bower plugin by running "ext install bower."
Press F1 and type Bower. Next type, "Bower Update."
This is it. The plugin will download the bootstrap package and populate it in wwwroot/lib directory. Now, the website would work as expected from within VSC.
Hope the next version of VSC will have bower integrated.
It seems like when your app runs from VS Code, it is not serving the CSS files.
To troubleshoot further, looking at the launch.json, project.json, and Startup.cs files is necessary. My guess is that your launch.json is setup to run under a slightly different configuration than your dotnet run command is from the terminal. That is resulting in...
not serving static files at all, or
not including CSS files in the app's build output.
From your question update, the problem is that your launch.json is running under in the Development environment and your terminal is running under the Staging or Production environment. The former serves bootstrap locally; the latter serves it from a content delivery network.
When running in the "Development" environment, you need to install bootstrap locally and ensure it's in the /lib directory at runtime. That means installing the client-side packages. How to do that depends on the ASP.NET Core application template your using. For instance, if you generated your app with Yeoman, then you need to restore with Bower. Check for a gulpfile.js, a bower.json file, or a package.json that downloads, installs, and builds client-side dependencies, which likely include bootstrap.
I would like to obfuscate my code. The tutorial is under Concatenation and minification topic
These are the steps I’ve used to minify the code in hybrid app:
export JAVA_HOME=$(/usr/libexec/java_home)
cd /Users/keatooon/Desktop/testmfpminify2
mfp create testProject
cd testProject
mfp add hybrid testApp
mfp start
mfp build
mfp push
mfp console
mfp push —concatenate —minify
xxx:testProject xxx$ mfp push --concatenate --minify
Preparing for push...
Verifying Server Configuration...
Runtime 'testProject' will be used to push the project into.
Pushing to Server...
Deploying
/Users/xxx/Desktop/wktestmfp2/testProject/bin/testApp-common.wlapp...
Deploy complete for
/Users/xxx/Desktop/wktestmfp2/testProject/bin/testApp-common.wlapp.
/Users/xxx/Desktop/wktestmfp2/testProject/bin/testApp-common.wlapp
has been deployed.
Push Completed Successfully.
However, it does not add any security to the code.
Code before vs after Concatenation and minification:
Moreover, the code doesn’t work at all after concatenating and minifying it.
Without specifying which files you want to minify, done in the build-settings.xml file located in the root folder of your application, nothing would actually get concatenated and/or minified.
The fact that it fails the app from running is interesting...
Have you edited said file? If not, try to.
Find more information about concatenation and minification, here:
Updating the build-settings.xml file: http://www.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.dev.doc/dev/c_optimize_app_cli.html
Configuring the build-settings.xml file: http://www.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.reference.doc/cli_commands/build_config.html
I have created a cocoa application primarily to run on OS 10.6.8. to convert certain types of proprietary legacy files. The app looks at the legacy files creator code and processes it accordingly if it is a known type. Once the file is identified, I call an external legacy app (which I have added to the project) using [NSWorkspace openFile: withApplication: ]to open the droplet and process the file conversion.
The application works just like it is supposed to until I archive it and try to run it from the application bundle. Actually, it will continue to work but it is using the converter app from the project. If I delete the converter in the project area, then the app in the app bundle can not open the external app in that location. One work around is to delete the external app from the bundle after its archived and replace it with a copy of the one in the project area.
I would appreciate any suggestions on resolving this. I'm not sure if the problem is in some Xcode build setting I can change to include an external apps resource fork when archiving, or if this is a launch services issue with apps hidden in packages, or , something I'm not even considering.
Thanks
Mike
Try setting the "Preserves HFS Data" (COPYING_PRESERVES_HFS_DATA) build setting.
Finding hard to know why am I unable to get this thing :
... I can run my application from command prompt, But when I do idea and Import the existing project using IntelliJ unable to trace out what Libraries or Jar files I need to get going.
In one Play1.2.3 I used to just Import Play and Play1.2.3 jar files and everything works..
Update
Have tried Creating a new project and Open Project(Instead of Import) from IntelliJ,But no luck.It has attached all the Libraries but still the error doesnt go screenshot attached:
IDE :IntelliJ 11.0.2 &
Play : 2.0.2
Since Play 2.0.2 you don't need to create Idea's project from the scratch and import modules into it.
Just choose Open project from the menu, and find the folder where you performed play idea action, whole project will be ready to use in the IDE without any additional steps.
Edit:
Most important: to reflect changes in managed sources your application need to compile it first, so it needs to work in the background while developing or you need to compile it manually if app is stopped. Otherwise Idea will not be able to compile (and find) managed sources. That's exactly job of the Play's DEV mode which differs from others Java frameworks, which requires to compile app manually and/or configuring your IDE to do that from time to time. Play's dev mode allows to do it in background.
Idea will start recognizing your managed sources after first run the app in the browser (as it will compile it, and idea will catch it just few seconds later). Of course the app must be running in dev mode, to compile views, assets etc.
play run
Of course if you're in production mode, you also need to restart the app.
alternatively after idealizing the project, or if your app is not working you can manually compile managed sources with:
play compile
Also if you'll start in tilde-dev mode, it will be compiling changed resources right after the changes' saving
play ~run